Skip to content
Fencer Vulns
medium 5.5

CVE-2022-50202 json

PM: hibernate: defer device probing when resuming from hibernation

published 2025-06-18 16 mo ago modified 2026-11-05 3 d ago also EUVD-2022-55464

cvss
5.5
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 16%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
  • linux Debian 14, Debian 13, Debian 12 6.0.2-1

debian advisories DEBIAN-CVE-2022-50202

  • linux Ubuntu 18.04 LTS 4.15.0-197.208
  • linux Ubuntu 20.04 LTS 5.4.0-132.148
  • linux Ubuntu 22.04 LTS 5.15.0-53.59
  • linux-aws Ubuntu 18.04 LTS 4.15.0-1143.155
  • linux-aws Ubuntu 20.04 LTS 5.4.0-1089.97
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1023.27
  • linux-gcp Ubuntu 20.04 LTS 5.4.0-1093.102
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1022.29

ubuntu advisories UBUNTU-CVE-2022-50202

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel RHEL 9 5.14.0-427.13.1.el9_4
  • rv RHEL 9 5.14.0-427.13.1.el9_4
  • perf RHEL 9 5.14.0-427.13.1.el9_4
  • rtla RHEL 9 5.14.0-427.13.1.el9_4
  • bpftool RHEL 9 7.3.0-427.13.1.el9_4
  • libperf RHEL 9 5.14.0-427.13.1.el9_4
  • kernel-rt RHEL 9 5.14.0-427.13.1.el9_4
  • kernel-64k RHEL 9 5.14.0-427.13.1.el9_4

red hat advisories RHSA-2024:2394

  • kernel-64kb SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS, SLE High Performance Computing 15 SP4-ESPOS 5.14.21-150400.24.170.2
  • kernel-syms SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +3 more 5.14.21-150400.24.170.1
  • kernel-source SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +3 more 5.14.21-150400.24.170.1
  • kernel-default SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +6 more 5.14.21-150400.24.170.2
  • kernel-zfcpdump SLES 15 SP4-LTSS, Manager Server 4.3 5.14.21-150400.24.170.2
  • kernel-obs-build SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +1 more 5.14.21-150400.24.170.2
  • kernel-default-base SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +5 more 5.14.21-150400.24.170.2.150400.24.86.2
  • kernel-rt SLE Micro 5.4, SLE Micro 5.3 5.14.21-150400.15.124.1

suse advisories SUSE-SU-2025:02537-1SUSE-SU-2025:02322-1SUSE-SU-2025:02321-1SUSE-SU-2025:02264-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2022-50202 updated cvss 4.7

kernel: PM: hibernate: defer device probing when resuming from hibernation

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-kvm, kernel-rt-core, kernel-rt-modules, kernel-rt-debug-kvm, kernel-rt-debug-core, +12 more
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux AppStream (v. 9) rv 5.14.0-427.13.1.el9_4, perf 5.14.0-427.13.1.el9_4, rtla 5.14.0-427.13.1.el9_4, kernel-devel-matched 5.14.0-427.13.1.el9_4, kernel-64k-devel-matched 5.14.0-427.13.1.el9_4, kernel-debug-devel-matched 5.14.0-427.13.1.el9_4, +6 more Red Hat Enterprise Linux BaseOS (v. 9) bpftool 7.3.0-427.13.1.el9_4, kernel 5.14.0-427.13.1.el9_4, kernel-64k 5.14.0-427.13.1.el9_4, kernel-core 5.14.0-427.13.1.el9_4, kernel-tools 5.14.0-427.13.1.el9_4, python3-perf 5.14.0-427.13.1.el9_4, +28 more Red Hat Enterprise Linux CRB (v. 9) libperf 5.14.0-427.13.1.el9_4, kernel-debuginfo-common-s390x 5.14.0-427.13.1.el9_4, kernel-debuginfo-common-x86_64 5.14.0-427.13.1.el9_4, kernel-debuginfo-common-aarch64 5.14.0-427.13.1.el9_4, kernel-debuginfo-common-ppc64le 5.14.0-427.13.1.el9_4 Red Hat Enterprise Linux NFV (v. 9) kernel-rt 5.14.0-427.13.1.el9_4, kernel-rt-kvm 5.14.0-427.13.1.el9_4, kernel-rt-core 5.14.0-427.13.1.el9_4, kernel-rt-modules 5.14.0-427.13.1.el9_4, kernel-rt-debug-kvm 5.14.0-427.13.1.el9_4, kernel-rt-debug-core 5.14.0-427.13.1.el9_4, +6 more Red Hat Enterprise Linux RT (v. 9) kernel-rt 5.14.0-427.13.1.el9_4, kernel-rt-core 5.14.0-427.13.1.el9_4, kernel-rt-modules 5.14.0-427.13.1.el9_4, kernel-rt-debug-core 5.14.0-427.13.1.el9_4, kernel-rt-modules-core 5.14.0-427.13.1.el9_4, kernel-rt-debug-modules 5.14.0-427.13.1.el9_4, +4 more
    fixed: vendor fix RHSA-2024:2394
  • Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
3 d ago

Exploit prediction

0.25% chance of exploitation in the next 30 days, higher than 16% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.