CVE-2022-50202

CVE-2022-50202 is a medium-severity vulnerability in Linux Linux Kernel with a CVSS 3.x base score of 5.5. It is not currently listed as actively exploited by CISA, and its EPSS exploit-prediction score is low.

Key facts

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.

Frequently asked questions

What is CVE-2022-50202?
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.
How severe is CVE-2022-50202?
CVE-2022-50202 has a CVSS 3.x base score of 5.5, rated medium severity. It is exploitable over local access with low attack complexity, requires low privileges and no user interaction. Impact on confidentiality is none, integrity none, and availability high.
Is CVE-2022-50202 being actively exploited?
It is not currently listed in CISA's KEV catalog. Its EPSS exploit-prediction score is 0% (11th percentile), an estimate of the probability of exploitation in the next 30 days.
What products are affected by CVE-2022-50202?
CVE-2022-50202 affects Linux Linux Kernel. See the affected-products list for the exact vulnerable versions.
How do I fix CVE-2022-50202?
Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround.
Does CVE-2022-50202 have an EU (EUVD) identifier?
Yes. CVE-2022-50202 is tracked in the ENISA EU Vulnerability Database (EUVD) as EUVD-2022-55464.
When was CVE-2022-50202 published?
CVE-2022-50202 was published on 2025-06-18 and last updated on 2026-06-17.

References

Affected products (1)

More vulnerabilities in Linux Linux Kernel

All CVEs affecting Linux Linux Kernel →