CVE-2024-57946

What it actually does

The virtio-blk driver freezes the request queue for the entire suspend context instead of using quiesce, which can deadlock on bio_queue_enter calls from suspend paths or other contexts attempting queue entry while the freeze is held.

Why it matters to the business

Systems using virtio-blk storage may experience deadlocks or lockdep warnings during power management operations, leading to failed suspend/resume cycles, potential data access stalls, and operational downtime especially on virtualized Linux environments with high downstream package prevalence.

How an attack unfolds

An attacker with local access triggers system suspend while inflight IO operations or bio_queue_enter callers are active on a virtio-blk device; the prolonged freeze creates a race that blocks queue entry, resulting in deadlock. Threat actors in 2024 Zero-Day Exploitation Campaigns by Espionage and Financially Motivated Actors or those targeting Linux Kernel Use of Uninitialized Resource Vulnerability have shown interest in similar kernel races for denial-of-service or escalation.

How to fix it

Upgrade Linux kernel to fixed versions including 5.4.289 or the commit d738f3215bb4f88911ff4579780a44960c8e0ca5; for Red Hat EAP7 apply eap7-jgroups 0:3.6.8-3.Final_redhat_3.1.ep7.el6 or 0:3.6.8-3.Final_redhat_3.1.ep7.el7. Restore previous quiesce behavior during suspend while draining inflight IOs via short freeze/unfreeze windows.

How to confirm the fix worked

Confirm kernel version matches or exceeds the listed fixed releases, verify absence of the original virtblk_freeze queue freeze logic in PM callbacks, and test suspend/resume cycles on virtio-blk devices without lockdep warnings or deadlocks.

Typical attack path

1. Gain local execution on a system with virtio-blk backed storage
2. Initiate or force a suspend transition while IO or bio operations are pending
3. Trigger the frozen queue state in virtblk_freeze that blocks bio_queue_enter
4. Observe deadlock or kernel warning preventing resume

How to detect it

Review kernel logs for lockdep warnings referencing virtblk_freeze or bio_queue_enter during suspend; inspect dmesg and systemd suspend logs for deadlock indicators or queue freeze messages on systems with virtio-blk; correlate with threat actor activity around Linux kernel race conditions.

What your security team should do

• Prioritize kernel updates on all virtio-blk hosts within the CISA-style remediation window if applicable
• Audit power management test suites to include virtio-blk suspend scenarios
• Monitor for related Linux kernel race condition reports from threat actors targeting out-of-bounds or uninitialized resource issues
• Apply updates to dependent packages such as Red Hat EAP7 jgroups where listed fixes are available