🇰🇷 한글 설명
리눅스 커널의 blk-mq 구성 요소에서 sbitmap 깨우기 경합 조건으로 인해 I/O 중단 현상이 발생할 수 있는 취약점입니다. blk_mq_mark_tag_wait() 함수 내에서 작업 순서가 재배치되면서 대기 큐에 추가된 대기자가 인식되지 않아 시스템이 멈출 수 있습니다.
💡 쉬운 설명
컴퓨터가 데이터를 읽고 쓰는 과정에서 순서가 꼬여서 데이터 처리가 영원히 멈춰버리는 문제입니다. 특정 상황에서 시스템이 응답하지 않는 '먹통' 상태가 될 수 있습니다.
🇺🇸 원문 (English)
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.
📍 영향받는 시스템
sbitmap을 사용하는 블록 멀티큐(blk-mq) 기반의 리눅스 커널 버전
⚔️ 공격 벡터
로컬 환경에서 특정 I/O 부하를 유발하여 시스템 중단을 일으키는 서비스 거부(DoS) 공격
🛡️ 대응 방법
blk_mq_mark_tag_wait() 함수에 명시적 배리어(barrier)를 추가하여 수정된 최신 리눅스 커널로 업데이트
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 패치된 버전인지 확인합니다.