ce833757 | 09-Oct-2024 |
Edward Adam Davis <eadavis@qq.com> |
USB: chaoskey: Fix possible deadlock chaoskey_list_lock
[ Upstream commit d73dc7b182be4238b75278bfae16afb4c5564a58 ]
[Syzbot reported two possible deadlocks] The first possible deadlock is: WARNING
USB: chaoskey: Fix possible deadlock chaoskey_list_lock
[ Upstream commit d73dc7b182be4238b75278bfae16afb4c5564a58 ]
[Syzbot reported two possible deadlocks] The first possible deadlock is: WARNING: possible recursive locking detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted -------------------------------------------- syz-executor363/2651 is trying to acquire lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x15d/0x2c0 drivers/usb/misc/chaoskey.c:322
but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x7f/0x2c0 drivers/usb/misc/chaoskey.c:299
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(chaoskey_list_lock); lock(chaoskey_list_lock);
*** DEADLOCK ***
The second possible deadlock is: WARNING: possible circular locking dependency detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted ------------------------------------------------------ kworker/0:2/804 is trying to acquire lock: ffffffff899dadb0 (minor_rwsem){++++}-{3:3}, at: usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186
but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_disconnect+0xa8/0x2a0 drivers/usb/misc/chaoskey.c:235
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (chaoskey_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x175/0x9c0 kernel/locking/mutex.c:752 chaoskey_open+0xdd/0x220 drivers/usb/misc/chaoskey.c:274 usb_open+0x186/0x220 drivers/usb/core/file.c:47 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x6cb/0x1390 fs/open.c:958 vfs_open+0x82/0x3f0 fs/open.c:1088 do_open fs/namei.c:3774 [inline] path_openat+0x1e6a/0x2d60 fs/namei.c:3933 do_filp_open+0x1dc/0x430 fs/namei.c:3960 do_sys_openat2+0x17a/0x1e0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (minor_rwsem){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain kernel/locking/lockdep.c:3904 [inline] __lock_acquire+0x250b/0x3ce0 kernel/locking/lockdep.c:5202 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5825 down_write+0x93/0x200 kernel/locking/rwsem.c:1577 usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186 chaoskey_disconnect+0xb7/0x2a0 drivers/usb/misc/chaoskey.c:236 usb_unbind_interface+0x1e8/0x970 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:569 [inline] device_remove+0x122/0x170 drivers/base/dd.c:561 __device_release_driver drivers/base/dd.c:1273 [inline] device_release_driver_internal+0x44a/0x610 drivers/base/dd.c:1296 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x396/0x9f0 drivers/base/core.c:3864 usb_disable_device+0x36c/0x7f0 drivers/usb/core/message.c:1418 usb_disconnect+0x2e1/0x920 drivers/usb/core/hub.c:2304 hub_port_connect drivers/usb/core/hub.c:5361 [inline] hub_port_connect_change drivers/usb/core/hub.c:5661 [inline] port_event drivers/usb/core/hub.c:5821 [inline] hub_event+0x1bed/0x4f40 drivers/usb/core/hub.c:5903 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(chaoskey_list_lock); lock(minor_rwsem); lock(chaoskey_list_lock); lock(minor_rwsem);
*** DEADLOCK *** [Analysis] The first is AA lock, it because wrong logic, it need a unlock. The second is AB lock, it needs to rearrange the order of lock usage.
Fixes: 422dc0a4d12d ("USB: chaoskey: fail open after removal") Reported-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=685e14d04fe35692d3bc Signed-off-by: Edward Adam Davis <eadavis@qq.com> Tested-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/tencent_84EB865C89862EC22EE94CB3A7C706C59206@qq.com Cc: Oliver Neukum <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
acfc4350 | 02-Oct-2024 |
Oliver Neukum <oneukum@suse.com> |
USB: chaoskey: fail open after removal
[ Upstream commit 422dc0a4d12d0b80dd3aab3fe5943f665ba8f041 ]
chaoskey_open() takes the lock only to increase the counter of openings. That means that the mutu
USB: chaoskey: fail open after removal
[ Upstream commit 422dc0a4d12d0b80dd3aab3fe5943f665ba8f041 ]
chaoskey_open() takes the lock only to increase the counter of openings. That means that the mutual exclusion with chaoskey_disconnect() cannot prevent an increase of the counter and chaoskey_open() returning a success.
If that race is hit, chaoskey_disconnect() will happily free all resources associated with the device after it has dropped the lock, as it has read the counter as zero.
To prevent this race chaoskey_open() has to check the presence of the device under the lock. However, the current per device lock cannot be used, because it is a part of the data structure to be freed. Hence an additional global mutex is needed. The issue is as old as the driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+422188bce66e76020e55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55 Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Rule: add Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20241002132201.552578-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
67970b0c | 24-Sep-2024 |
Oliver Neukum <oneukum@suse.com> |
usb: yurex: make waiting on yurex_write interruptible
[ Upstream commit e0aa9614ab0fd35b404e4b16ebe879f9fc152591 ]
The IO yurex_write() needs to wait for in order to have a device ready for writing
usb: yurex: make waiting on yurex_write interruptible
[ Upstream commit e0aa9614ab0fd35b404e4b16ebe879f9fc152591 ]
The IO yurex_write() needs to wait for in order to have a device ready for writing again can take a long time time. Consequently the sleep is done in an interruptible state. Therefore others waiting for yurex_write() itself to finish should use mutex_lock_interruptible.
Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 6bc235a2e24a5 ("USB: add driver for Meywa-Denki & Kayac YUREX") Rule: add Link: https://lore.kernel.org/stable/20240924084415.300557-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20240924084415.300557-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
22564331 | 12-Sep-2024 |
Oliver Neukum <oneukum@suse.com> |
USB: misc: yurex: fix race between read and write
[ Upstream commit 93907620b308609c72ba4b95b09a6aa2658bb553 ]
The write code path touches the bbu member in a non atomic manner without taking the s
USB: misc: yurex: fix race between read and write
[ Upstream commit 93907620b308609c72ba4b95b09a6aa2658bb553 ]
The write code path touches the bbu member in a non atomic manner without taking the spinlock. Fix it.
The bug is as old as the driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240912132126.1034743-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
7bcd961d | 12-Sep-2024 |
Oliver Neukum <oneukum@suse.com> |
USB: misc: cypress_cy7c63: check for short transfer
commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream.
As we process the second byte of a control transfer, transfers of less than 2 bytes mus
USB: misc: cypress_cy7c63: check for short transfer
commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream.
As we process the second byte of a control transfer, transfers of less than 2 bytes must be discarded.
This bug is as old as the driver.
SIgned-off-by: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240912125449.1030536-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
f87ba66a | 04-Aug-2023 |
Ruan Jinjie <ruanjinjie@huawei.com> |
USB: misc: Remove unnecessary NULL values
The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, o
USB: misc: Remove unnecessary NULL values
The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230804093253.91647-3-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
ebcf7746 | 04-Aug-2023 |
Ruan Jinjie <ruanjinjie@huawei.com> |
USB: cytherm: Correct the code style issue of redundant spaces
Ther are many redundant spaces, which is not consistent with the kernel code style, so remove it.
Signed-off-by: Ruan Jinjie <ruanjinj
USB: cytherm: Correct the code style issue of redundant spaces
Ther are many redundant spaces, which is not consistent with the kernel code style, so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230804091713.41503-1-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
b43cd82a | 23-Jun-2023 |
Benjamin Bara <benjamin.bara@skidata.com> |
usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family
The HX3 comes in different variants (up to 4 USB 3.0 ports; multi-TT), e.g. CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x. It operates wi
usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family
The HX3 comes in different variants (up to 4 USB 3.0 ports; multi-TT), e.g. CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x. It operates with two different power supplies: 1V2 and 3V3.
Add the support for this hub, for controlling the reset pin and the power supplies.
Reset time is extracted from data sheet, page 24: "The RESETN pin can be tied to VDD_IO through an external resistor and to ground (GND) through an external capacitor (minimum 5 ms time constant)." V_IH min is given at 0.7 * 3V3 (page 34), therefore use 10ms.
Also add USB PIDs for the USB 2.0 and USB 3.0 root hub.
Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230620-hx3-v7-2-f79b4b22a1bf@skidata.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
56dcc717 | 30-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
usb: misc: onboard_hub: Don't warn twice about problems during remove
If onboard_hub_power_off() called by onboard_hub_remove() fails it emits an error message. Forwarding the returned error value t
usb: misc: onboard_hub: Don't warn twice about problems during remove
If onboard_hub_power_off() called by onboard_hub_remove() fails it emits an error message. Forwarding the returned error value to the driver core results in another error message. As the return value is otherwise ignored, just drop the return value. There is no side effect apart from suppressing the core's warning.
Instead of returning zero unconditionally, convert to .remove_new() which has the same semantics as .remove() that unconditionally returns zero.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230530073633.2193618-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|