LiveActive security incident?Get immediate response
CVE Record

CVE-2022-50202: PM: hibernate: defer device probing when resuming from hibernation

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2022-50202 is a Linux kernel hibernation bug that can leave a system hung while opening the snapshot interface. The reported trigger involves USB device probing and raw-gadget emulation. Business impact is availability, not confirmed data theft or remote code execution, based on the supplied sources.

Executive priority

Handle through normal kernel patch governance, with higher priority for laptops, lab systems, embedded Linux, or environments using USB gadget emulation. No active exploitation is supported by the supplied sources, but availability failures during hibernation can disrupt operations.

Technical view

The issue is an AB-BA deadlock around probe_count, misc_mtx, and system_transition_mutex. snapshot_open() calls wait_for_device_probe() while holding misc_mtx; a USB probe from hub_event() may wait on raw-gadget userspace that is blocked on misc_mtx. The kernel fix defers waiting from snapshot_open() to snapshot_write() and snapshot_ioctl().

Likely exposure

Exposure appears most relevant to Linux systems using hibernation paths, /dev/snapshot, USB device probing, and especially /dev/raw-gadget device emulation. The source also notes broken or malicious hardware and continuous new probe requests as unresolved related cases.

Exploitation context

The bundle does not show CISA KEV listing or any cited active exploitation. The documented report came from syzbot and describes a hung task/deadlock condition. Treat this as a local or device-adjacent availability risk unless vendor advisories state otherwise.

Researcher notes

The fix mitigates the syzbot-reported raw-gadget deadlock case by moving wait_for_device_probe(). The source explicitly says broken or malicious hardware and continuous incoming probe requests are not addressed, and raw-gadget blocking risk may remain under some conditions.

Mitigation direction

  • Update affected Linux kernels to vendor builds containing the referenced stable fixes.
  • Prioritize systems using hibernation, USB gadget testing, or raw-gadget interfaces.
  • Restrict access to raw-gadget functionality where it is not operationally required.
  • Review vendor kernel advisories for distribution-specific fixed versions.
  • Consider disabling hibernation on exposed or high-availability systems if patching is delayed.

Validation and detection

  • Inventory Linux kernel versions across servers, endpoints, appliances, and test rigs.
  • Check whether hibernation and /dev/snapshot are enabled or used.
  • Identify systems exposing or using /dev/raw-gadget for USB emulation.
  • Confirm installed kernels include the stable commits referenced by the CVE record.
  • Monitor for hung task reports involving misc_open(), snapshot_open(), or wait_for_device_probe().
Prepared
Confidence
high
Sources
10

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2022-50202 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
9Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxc751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202, c751085943362143f84346d274e0011419c84202unaffected
LinuxLinux2.6.30, 0, 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.