Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]USB: gadget: Fix obscure lockdep violation for udc_mutex[EOL][EOL]A recent commit expanding the scope of the udc_lock mutex in the[EOL]gadget core managed to cause an obscure and slightly bizarre lockdep[EOL]violation.  In abbreviated form:[EOL][EOL]======================================================[EOL]WARNING: possible circular locking dependency detected[EOL]5.19.0-rc7+ #12510 Not tainted[EOL]------------------------------------------------------[EOL]udevadm/312 is trying to acquire lock:[EOL]ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0[EOL][EOL]but task is already holding lock:[EOL]ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0[EOL][EOL]which lock already depends on the new lock.[EOL][EOL]the existing dependency chain (in reverse order) is:[EOL][EOL]-> #3 (kn->active#4){++++}-{0:0}:[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 lock_acquire+0x68/0x84[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __kernfs_remove+0x268/0x380[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 kernfs_remove_by_name_ns+0x58/0xac[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 sysfs_remove_file_ns+0x18/0x24[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 device_del+0x15c/0x440[EOL][EOL]-> #2 (device_links_lock){+.+.}-{3:3}:[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 lock_acquire+0x68/0x84[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __mutex_lock+0x9c/0x430[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 mutex_lock_nested+0x38/0x64[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 device_link_remove+0x3c/0xa0[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 _regulator_put.part.0+0x168/0x190[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 regulator_put+0x3c/0x54[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 devm_regulator_release+0x14/0x20[EOL][EOL]-> #1 (regulator_list_mutex){+.+.}-{3:3}:[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 lock_acquire+0x68/0x84[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __mutex_lock+0x9c/0x430[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 mutex_lock_nested+0x38/0x64[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 regulator_lock_dependent+0x54/0x284[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 regulator_enable+0x34/0x80[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 phy_power_on+0x24/0x130[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __dwc2_lowlevel_hw_enable+0x100/0x130[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 dwc2_lowlevel_hw_enable+0x18/0x40[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 dwc2_hsotg_udc_start+0x6c/0x2f0[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 gadget_bind_driver+0x124/0x1f4[EOL][EOL]-> #0 (udc_lock){+.+.}-{3:3}:[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __lock_acquire+0x1298/0x20cc[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 lock_acquire.part.0+0xe0/0x230[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 lock_acquire+0x68/0x84[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 __mutex_lock+0x9c/0x430[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 mutex_lock_nested+0x38/0x64[EOL] Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0Â\xa0 usb_udc_uevent+0x54/0xe0[EOL][EOL]Evidently this was caused by the scope of udc_mutex being too large.[EOL]The mutex is only meant to protect udc->driver along with a few other[EOL]things.  As far as I can tell, there's no reason for the mutex to be[EOL]held while the gadget core calls a gadget driver's ->bind or ->unbind[EOL]routine, or while a UDC is being started or stopped.  (This accounts[EOL]for link #1 in the chain above, where the mutex is held while the[EOL]dwc2_hsotg_udc is started as part of driver probing.)[EOL][EOL]Gadget drivers' ->disconnect callbacks are problematic.  Even though[EOL]usb_gadget_disconnect() will now acquire the udc_mutex, there's a[EOL]window in usb_gadget_bind_driver() between the times when the mutex is[EOL]released and the ->bind callback is invoked.  If a disconnect occurred[EOL]during that window, we could call the driver's ->disconnect routine[EOL]before its ->bind routine.  To prevent this from happening, it will be[EOL]necessary to prevent a UDC from connecting while it has no gadget[EOL]driver.  This should be done already but it doesn't seem to be;[EOL]currently usb_gadget_connect() has no check for this.  Such a check[EOL]will have to be added later.[EOL][EOL]Some degree of mutual exclusion is required in soft_connect_store(),[EOL]which can dereference udc->driver at arbitrary times since it is a[EOL]sysfs callback.  The solution here is to acquire the gadget's device[EOL]lock rather than the udc_mutex.  Since the driver core guarantees that[EOL]the device lock is always held during driver binding and unbinding,[EOL]this will make the accesses in soft_connect_store() mutually exclusive[EOL]with any changes to udc->driver.[EOL][EOL]Lastly, it turns out there is one place which should hold the[EOL]udc_mutex but currently does not: The function_show() routine needs[EOL]protection while it dereferences udc->driver.  The missing lock and[EOL]unlock calls are added.

CREATE(Triage):(User=lchen-cn) [CVE-2022-49943 (https://nvd.nist.gov/vuln/detail/CVE-2022-49943)