Acknowledged
Created: Jun 18, 2025
Updated: Sep 4, 2026
Resolved Date: Jun 19, 2025
Found In Version: 10.25.33.1
Severity: Standard
Applicable for: Wind River Linux LTS 25
Component/s: Kernel
In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]PM: hibernate: defer device probing when resuming from hibernation[EOL][EOL]syzbot is reporting hung task at misc_open() [1], for there is a race[EOL]window of AB-BA deadlock which involves probe_count variable. Currently[EOL]wait_for_device_probe() from snapshot_open() from misc_open() can sleep[EOL]forever with misc_mtx held if probe_count cannot become 0.[EOL][EOL]When a device is probed by hub_event() work function, probe_count is[EOL]incremented before the probe function starts, and probe_count is[EOL]decremented after the probe function completed.[EOL][EOL]There are three cases that can prevent probe_count from dropping to 0.[EOL][EOL] (a) A device being probed stopped responding (i.e. broken/malicious[EOL] hardware).[EOL][EOL] (b) A process emulating a USB device using /dev/raw-gadget interface[EOL] stopped responding for some reason.[EOL][EOL] (c) New device probe requests keeps coming in before existing device[EOL] probe requests complete.[EOL][EOL]The phenomenon syzbot is reporting is (b). A process which is holding[EOL]system_transition_mutex and misc_mtx is waiting for probe_count to become[EOL]0 inside wait_for_device_probe(), but the probe function which is called[EOL] from hub_event() work function is waiting for the processes which are[EOL]blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.[EOL][EOL]This patch mitigates (b) by deferring wait_for_device_probe() from[EOL]snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that[EOL]the possibility of (b) remains as long as any thread which is emulating a[EOL]USB device via /dev/raw-gadget interface can be blocked by uninterruptible[EOL]blocking operations (e.g. mutex_lock()).[EOL][EOL]Please also note that (a) and (c) are not addressed. Regarding (c), we[EOL]should change the code to wait for only one device which contains the[EOL]image for resuming from hibernation. I don't know how to address (a), for[EOL]use of timeout for wait_for_device_probe() might result in loss of user[EOL]data in the image. Maybe we should require the userland to wait for the[EOL]image device before opening /dev/snapshot interface.
CREATE(Triage):(User=lchen-cn) [CVE-2022-50202 (https://nvd.nist.gov/vuln/detail/CVE-2022-50202)