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(&amp;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&amp;#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