CVE-2024-26671: blk-mq: fix IO hang from sbitmap wakeup race

Severity: medium (CVSS 4.7 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-04-02 · updated 2026-10-15
Weakness: CWE-362

Description

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.

Affected products

Debian Linux: 10.0
Linux kernel: before 4.19.307; from 4.20 before 5.4.269; from 5.5 before 5.10.210; from 5.11 before 5.15.149; from 5.16 before 6.1.77; from 6.2 before 6.7.4 — fixed in 4.19.307, 5.10.210, 5.15.149, 5.4.269, 6.1.77, 6.7.4

How to fix

Upgrade to a fixed version: Linux kernel 4.19.307, 5.10.210, 5.15.149, 5.4.269. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2024-26671 or the next vulnerability affects your stack