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 miscopen() [1], for there is a race window of AB-BA deadlock which involves probecount variable. Currently waitfordeviceprobe() from snapshotopen() from miscopen() can sleep forever with miscmtx held if probe_count cannot become 0.

When a device is probed by hubevent() work function, probecount 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 systemtransitionmutex and miscmtx is waiting for probecount to become 0 inside waitfordeviceprobe(), but the probe function which is called from hubevent() work function is waiting for the processes which are blocked at mutexlock(&miscmtx) to respond via /dev/raw-gadget interface.

This patch mitigates (b) by deferring waitfordeviceprobe() from snapshotopen() to snapshotwrite() and snapshotioctl(). 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 waitfordevice_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.