CVE-2022-50202
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-18

Last updated on: 2025-11-19

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-18
Last Modified
2025-11-19
Generated
2026-05-07
AI Q&A
2025-06-18
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50202
Affected Vendors & Products
Showing 7 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a race condition and potential deadlock during device probing when resuming from hibernation. Specifically, a variable called probe_count, which tracks ongoing device probes, may never reach zero due to certain conditions, causing the system to hang. One key scenario is when a process emulating a USB device via the /dev/raw-gadget interface stops responding, leading to a deadlock where the system waits indefinitely for device probes to complete while holding critical mutexes. The patch defers waiting for device probes to later stages to mitigate this issue, but some risk remains if the emulating process is blocked.


How can this vulnerability impact me? :

This vulnerability can cause the system to hang indefinitely during resume from hibernation if a device probe does not complete, particularly when a USB device emulation process becomes unresponsive. This can lead to system instability, inability to resume properly, and potential denial of service conditions.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that defers wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(), which reduces the risk of the deadlock caused by processes emulating USB devices via /dev/raw-gadget interface. Additionally, avoid running processes that emulate USB devices using /dev/raw-gadget interface that may block on uninterruptible operations such as mutex_lock(). Note that other cases (a) and (c) are not addressed by this patch, so monitoring and managing device probe requests and hardware responsiveness is also advisable.


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