Message-ID: <2025061840-CVE-2022-50202-48e0@gregkh>
Date: Wed, 18 Jun 2025 13:04:27 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50202: PM: hibernate: defer device probing when resuming from hibernation

From: Greg Kroah-Hartman <gregkh@...nel.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.

The Linux kernel CVE team has assigned CVE-2022-50202 to this issue.


Affected and fixed versions
===========================

	Fixed in 4.14.291 with commit 8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
	Fixed in 4.19.256 with commit 5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
	Fixed in 5.4.211 with commit 3c48d3067eaf878642276f053575a5c642600a50
	Fixed in 5.10.137 with commit 003a456ae6f70bb97e436e02fc5105be577c1570
	Fixed in 5.15.61 with commit 2f0e18e0db42f4f8bc87d3d98333680065ceeff8
	Fixed in 5.18.18 with commit b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
	Fixed in 5.19.2 with commit f7042cf9dd40733f387b7cac021e626c74b8856f
	Fixed in 6.0 with commit 8386c414e27caba8501119948e9551e52b527f59

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50202
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/power/user.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
	https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
	https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
	https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570
	https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8
	https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
	https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f
	https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59

Powered by blists - more mailing lists