CVE-2022-49943: In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix obscure lockdep violation for udc_mutex A recent commit expanding the…

PriorityP423medium5.5CVSS 3.1

AVLACLPRLUINSUCNINAH

EPSS

0.14%

3.9th percentile

In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix obscure lockdep violation for udc_mutex A recent commit expanding the scope of the udc_lock mutex in the gadget core managed to cause an obscure and slightly bizarre lockdep violation. In abbreviated form: WARNING: possible circular locking dependency detected 5.19.0-rc7+ #12510 Not tainted udevadm/312 is trying to acquire lock: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0 but task is already holding lock: ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (regulator_list_mutex){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidently this was caused by the scope of udc_mutex being too large. The mutex is only meant to protect udc->driver along with a few other things. As far as I can tell, there's no reason for the mutex to be held while the gadget core calls a gadget driver's ->bind or ->unbind routine, or while a UDC is being started or stopped. (This accounts for link #1 in

Affected

9 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.0.2-1 (bookworm)	linux 6.0.2-1 (bookworm)
linux	linux	>= 2191c00855b03aa59c20e698be713d952d51fc18 < 1016fc0c096c92dd0e6e0541daac7a7868169903	1016fc0c096c92dd0e6e0541daac7a7868169903
linux	linux	>= 5.19.7 < 5.19.8	5.19.8
linux	linux	>= f44b0b95d50fffeca036e1ba36770390e0b519dd < 1a065e4673cbdd9f222a05f85e17d78ea50c8d9c	1a065e4673cbdd9f222a05f85e17d78ea50c8d9c
linux	linux_kernel	—	—
linux	linux_kernel	—	—
linux	linux_kernel	>= 0 < 6.0.2-1	6.0.2-1
linux	linux_kernel	>= 0 < 6.0.2-1	6.0.2-1
linux	linux_kernel	>= 0 < 6.0.2-1	6.0.2-1

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv5.5MEDIUM

vendor_debian5.5MEDIUM

vendor_redhat5.5MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.