CVE-2024-57946: virtio-blk: don't keep queue frozen during system suspend
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: don't keep queue frozen during system suspend
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of ->suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().
[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
Given the motivation is to drain in-flight IOs, it can be done by calling
freeze & unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can make affected systems hang during power management suspend because virtio-blk may leave a block queue frozen too long. The direct business impact is availability: workloads could stall or require recovery if suspend paths are reached on vulnerable systems.
Executive priority
Treat as a moderate availability risk. It is not described as data theft or remote compromise, but kernel-level hangs can disrupt services, especially in virtualized environments. Patch through normal kernel maintenance with priority for exposed virtio-blk systems.
Technical view
The flaw is in virtio-blk power-management callbacks. A prior change used queue freeze to drain in-flight I/O before suspend, but keeping the queue frozen across suspend can deadlock callers entering bio_queue_enter(). The fix restores quiesced suspend behavior while briefly freezing and unfreezing to drain I/O.
Likely exposure
Exposure is most relevant to Linux systems using virtio-blk block devices on affected kernel versions or downstream packages. The provided data names Linux as the affected product and lists stable kernel fixes and Debian LTS advisories.
Exploitation context
The CVSS vector is local, low complexity, low privileges, no user interaction, with high availability impact. The source bundle does not show KEV listing or cited active exploitation evidence.
Researcher notes
Evidence is specific to Linux virtio-blk suspend behavior and CWE-667 locking. The bundle provides stable commit references but not complete downstream package mapping for all distributions. Avoid assuming exploit availability; validation should focus on kernel lineage, driver presence, and vendor advisory status.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize virtualized Linux systems using virtio-blk storage.
Review Debian LTS advisories if running affected Debian packages.
Check your distribution advisory before relying on workarounds.
Schedule reboot or live-patching per standard kernel update process.
Validation and detection
Inventory Linux kernel versions across affected assets.
Confirm whether virtio-blk devices are present on those systems.
Verify the applicable stable fix is included in the running kernel.
Check Debian advisory coverage for Debian LTS hosts.
Regression test suspend and resume where that path is operationally used.
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.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.