CVE-2024-26671: blk-mq: fix IO hang from sbitmap wakeup race
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix IO hang from sbitmap wakeup race
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
with the following blk_mq_get_driver_tag() in case of getting driver
tag failure.
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
blk_mq_mark_tag_wait() can't get driver tag successfully.
This issue can be reproduced by running the following test in loop, and
fio hang can be observed in < 30min when running it on my test VM
in laptop.
modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
--runtime=100 --numjobs=40 --time_based --name=test \
--ioengine=libaio
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag.
Security readout for executives and security teams
Plain-English summary
CVE-2024-26671 is a Linux kernel block I/O bug that can cause storage operations to hang. The source describes a race in wakeup handling when driver tags are exhausted. Business impact is service degradation or outage on affected Linux systems, especially where storage I/O is heavy.
Executive priority
Treat as availability risk, not confirmed active attack. Schedule kernel updates through normal emergency or high-priority maintenance depending on business dependence on Linux storage reliability.
Technical view
The issue is in blk-mq tag waiting: queue insertion may be reordered with a later driver-tag allocation attempt. __sbitmap_queue_wake_up() may miss the waiter, leaving I/O stuck. The kernel fix adds an explicit barrier in blk_mq_mark_tag_wait().
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or ranges identified by kernel and distribution sources. Prioritize servers, virtualization hosts, and storage-heavy workloads where an I/O hang would affect availability.
Exploitation context
The bundle does not show CISA KEV listing or active exploitation. The kernel description says the condition was reproducible in a test environment and caused fio to hang, but no malicious exploitation evidence is cited.
Researcher notes
Severity and CVSS are not provided in the bundle. Analysis should stay tied to kernel and distribution advisories. The primary security concern is denial of service through an I/O hang, with incomplete evidence for exploitability beyond reproduction.
Mitigation direction
Update affected Linux kernels through the operating system vendor or stable kernel channel.
Confirm the update includes the blk-mq sbitmap wakeup race fix.
Review Debian LTS advisories if running Debian-based affected systems.
Prioritize remediation for production systems with high storage I/O or availability requirements.
Validation and detection
Inventory Linux kernel versions across production and staging systems.
Compare installed kernels against vendor advisories and referenced stable commits.
Verify updated systems include the relevant stable kernel fix.
Monitor for recurring I/O hangs, blocked tasks, or storage latency anomalies after update.
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-2024-26671 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.