CVE-2022-49943
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-18

Last updated on: 2025-11-14

Assigner: kernel.org

Description
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 the chain above, where the mutex is held while the dwc2_hsotg_udc is started as part of driver probing.) Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadget_disconnect() will now acquire the udc_mutex, there's a window in usb_gadget_bind_driver() between the times when the mutex is released and the ->bind callback is invoked. If a disconnect occurred during that window, we could call the driver's ->disconnect routine before its ->bind routine. To prevent this from happening, it will be necessary to prevent a UDC from connecting while it has no gadget driver. This should be done already but it doesn't seem to be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later. Some degree of mutual exclusion is required in soft_connect_store(), which can dereference udc->driver at arbitrary times since it is a sysfs callback. The solution here is to acquire the gadget's device lock rather than the udc_mutex. Since the driver core guarantees that the device lock is always held during driver binding and unbinding, this will make the accesses in soft_connect_store() mutually exclusive with any changes to udc->driver. Lastly, it turns out there is one place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it dereferences udc->driver. The missing lock and unlock calls are added.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-18
Last Modified
2025-11-14
Generated
2026-05-07
AI Q&A
2025-06-18
EPSS Evaluated
2026-05-05
NVD
CVE-2022-49943
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.19.7
linux linux_kernel 6.0
linux linux_kernel 6.0
linux linux_kernel 6.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a lock dependency violation in the Linux kernel's USB gadget subsystem. It occurs because the scope of the udc_lock mutex was expanded too broadly, causing a circular locking dependency. This can lead to potential deadlocks or unpredictable behavior when the kernel tries to acquire locks in an order that conflicts with existing locks. The issue arises especially during gadget driver binding, unbinding, and UDC start/stop operations, where the mutex was held longer than necessary. The fix involves narrowing the mutex scope, adding proper locking checks, and ensuring mutual exclusion using the device lock instead of the udc_mutex in certain sysfs callbacks.


How can this vulnerability impact me? :

This vulnerability can cause obscure lockdep warnings indicating circular locking dependencies, which may lead to kernel deadlocks or instability in the USB gadget subsystem. Such instability can affect the reliability of USB device functions on affected Linux systems, potentially causing device malfunctions or system hangs during USB gadget operations.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update your Linux kernel to a version that includes the fix for the udc_mutex lockdep violation. The fix involves reducing the scope of the udc_mutex to avoid holding it during gadget driver bind/unbind and UDC start/stop operations, and adding necessary locking in sysfs callbacks and function_show() routines. Ensuring your system runs the patched kernel version will prevent the obscure lockdep violation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart