Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2024-26671

Опубликовано: 02 апр. 2024
Источник: redhat
CVSS3: 4.4
EPSS Низкий

Описание

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.

A possible IO hang from sbitmap wakeup race was found in the Linux kernel. This may lead to compromised Availability.

Отчет

This issue is fixed in RHEL-9.4 and above (including RHEL 8.10)

a7f97b4cae32 (in rhel-9.4, rhel-9.5) blk-mq: fix IO hang from sbitmap wakeup race 098ab94a5112 (in rhel-8.10) blk-mq: fix IO hang from sbitmap wakeup race

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.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 6kernelOut of support scope
Red Hat Enterprise Linux 7kernelOut of support scope
Red Hat Enterprise Linux 7kernel-rtOut of support scope
Red Hat Enterprise Linux 9kernel-rtAffected
Red Hat Enterprise Linux 8kernel-rtFixedRHSA-2024:295022.05.2024
Red Hat Enterprise Linux 8kernelFixedRHSA-2024:313822.05.2024
Red Hat Enterprise Linux 8.8 Extended Update SupportkernelFixedRHSA-2024:1026226.11.2024
Red Hat Enterprise Linux 9kernelFixedRHSA-2024:239430.04.2024
Red Hat Enterprise Linux 9kernelFixedRHSA-2024:239430.04.2024
Red Hat Enterprise Linux 9.0 Update Services for SAP SolutionskernelFixedRHSA-2024:994219.11.2024

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-362
https://bugzilla.redhat.com/show_bug.cgi?id=2272811kernel: blk-mq: fix IO hang from sbitmap wakeup race

EPSS

Процентиль: 1%
0.00009
Низкий

4.4 Medium

CVSS3

Связанные уязвимости

CVSS3: 4.7
ubuntu
почти 2 года назад

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 ...

CVSS3: 4.7
nvd
почти 2 года назад

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

CVSS3: 4.7
msrc
7 месяцев назад

blk-mq: fix IO hang from sbitmap wakeup race

CVSS3: 4.7
debian
почти 2 года назад

In the Linux kernel, the following vulnerability has been resolved: b ...

CVSS3: 4.7
github
почти 2 года назад

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

Процентиль: 1%
0.00009
Низкий

4.4 Medium

CVSS3