Описание
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.
Отчет
This issue is fixed in RHEL-9.4 and above (including RHEL 8.10)
Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata. Within regulated environments, a combination of the following controls acts as a significant barrier to successfully exploiting a CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability and therefore downgrades the severity of this particular CVE from Moderate to Low. Red Hat enforces the principle of least functionality, ensuring that only essential features, services, and ports are enabled. The environment leverages malicious code protections such as IPS/IDS and antimalware solutions that detect and respond to indicators in real time, limiting the impact of exploitation attempts. Static code analysis and peer code review techniques are used to execute robust input validation and error-handling mechanisms to ensure all user inputs are thoroughly validated, preventing improperly validated inputs from causing system instability, exposing sensitive data, or escalating risks. In the case of successful exploitation, detection and containment controls are in place to limit impacts by alerting on anomalous system behavior in real time, while process isolation and automated orchestration via Kubernetes minimize the likelihood of concurrent execution scenarios that would trigger the race condition and help contain the impact to a single process.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Out of support scope | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2024:2950 | 22.05.2024 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2024:3138 | 22.05.2024 |
| Red Hat Enterprise Linux 8.8 Extended Update Support | kernel | Fixed | RHSA-2024:10262 | 26.11.2024 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:2394 | 30.04.2024 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:2394 | 30.04.2024 |
| Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions | kernel | Fixed | RHSA-2024:9942 | 19.11.2024 |
Показывать по
Дополнительная информация
Статус:
EPSS
4.4 Medium
CVSS3
Связанные уязвимости
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 ...
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
In the Linux kernel, the following vulnerability has been resolved: b ...
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=liba...
EPSS
4.4 Medium
CVSS3