CVE-2022-50202
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
18/06/2025
Last modified:
18/06/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
PM: hibernate: defer device probing when resuming from hibernation<br />
<br />
syzbot is reporting hung task at misc_open() [1], for there is a race<br />
window of AB-BA deadlock which involves probe_count variable. Currently<br />
wait_for_device_probe() from snapshot_open() from misc_open() can sleep<br />
forever with misc_mtx held if probe_count cannot become 0.<br />
<br />
When a device is probed by hub_event() work function, probe_count is<br />
incremented before the probe function starts, and probe_count is<br />
decremented after the probe function completed.<br />
<br />
There are three cases that can prevent probe_count from dropping to 0.<br />
<br />
(a) A device being probed stopped responding (i.e. broken/malicious<br />
hardware).<br />
<br />
(b) A process emulating a USB device using /dev/raw-gadget interface<br />
stopped responding for some reason.<br />
<br />
(c) New device probe requests keeps coming in before existing device<br />
probe requests complete.<br />
<br />
The phenomenon syzbot is reporting is (b). A process which is holding<br />
system_transition_mutex and misc_mtx is waiting for probe_count to become<br />
0 inside wait_for_device_probe(), but the probe function which is called<br />
from hub_event() work function is waiting for the processes which are<br />
blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.<br />
<br />
This patch mitigates (b) by deferring wait_for_device_probe() from<br />
snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that<br />
the possibility of (b) remains as long as any thread which is emulating a<br />
USB device via /dev/raw-gadget interface can be blocked by uninterruptible<br />
blocking operations (e.g. mutex_lock()).<br />
<br />
Please also note that (a) and (c) are not addressed. Regarding (c), we<br />
should change the code to wait for only one device which contains the<br />
image for resuming from hibernation. I don&#39;t know how to address (a), for<br />
use of timeout for wait_for_device_probe() might result in loss of user<br />
data in the image. Maybe we should require the userland to wait for the<br />
image device before opening /dev/snapshot interface.
Impact
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570
- https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8
- https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
- https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
- https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59
- https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
- https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
- https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f