跳转到帖子

Red Hat: CVE-2024-26671: kernel: blk-mq: fix IO hang from sbitmap wakeup race (Multiple Advisories)

recommended_posts

发布于
  • Members

Red Hat: CVE-2024-26671: kernel: blk-mq: fix IO hang from sbitmap wakeup race (Multiple Advisories)

Severity
4
CVSS
(AV:L/AC:L/Au:M/C:N/I:N/A:C)
Published
04/02/2024
Created
05/24/2024
Added
05/23/2024
Modified
02/10/2025

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.

Solution(s)

  • redhat-upgrade-kernel
  • redhat-upgrade-kernel-rt

References

  • CVE-2024-26671
  • RHSA-2024:10262
  • RHSA-2024:2950
  • RHSA-2024:3138
  • RHSA-2024:8613
  • RHSA-2024:8614
  • 查看数 700
  • 已创建
  • 最后回复

参与讨论

你可立刻发布并稍后注册。 如果你有帐户,立刻登录发布帖子。
注意:你的帖子需要版主批准后才能看到。

游客
回帖…