🇰🇷 한글 설명
Linux 커널의 null_blk 드라이버에서 configfs 속성 저장 시 잠금(lock) 메커니즘이 누락되어 발생하는 레이스 컨디션 취약점입니다. 이로 인해 장치 설정 중 데이터가 불일치하거나, 잘못된 인덱스 접근으로 인한 메모리 범위 초과(out-of-bounds)가 발생할 수 있습니다.
💡 쉬운 설명
장치 설정을 변경하는 과정에서 여러 명령이 동시에 들어올 경우, 설정값이 꼬이거나 시스템이 잘못된 메모리 영역을 건드려 오류가 발생할 수 있는 문제입니다. 마치 여러 사람이 동시에 하나의 서류를 수정하려고 할 때 순서가 맞지 않아 내용이 망가지는 것과 같습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
null_blk: serialize configfs attribute stores with the lock
The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes
(submit_queues, poll_queues) get dev->NAME written again after apply_fn
returns, outside its lock; APPLY=NULL attributes are entirely lockless.
configfs only serializes stores per-open-file, so concurrent stores on
separate fds race.
For apply_fn attributes, once one store's apply_fn has reconfigured the
hardware, a second (losing) store can still overwrite dev->NAME
afterwards. This leaves dev->submit_queues out of sync with the live
queue count, which is later caught by the WARN_ON_ONCE() in
null_map_queues().
For !apply_fn attributes, power_store()'s null_add_dev() validates and
builds the device under "lock" but only sets CONFIGURED afterwards. A store
slipping in during this window can change a field mid-setup -- for example,
zone_nr_conv can be pushed above nr_zones after it has already been
clamped, leading to an out-of-bounds dev->zones[] access.
Take "lock" in the macro around the apply_fn call, the CONFIGURED test and
the field write, and move it out of nullb_apply_submit_queues()/
nullb_apply_poll_queues() so both paths are covered once. This serializes
stores with power_store's setup and with each other.
📍 영향받는 시스템
Linux kernel (null_blk 드라이버를 사용하는 버전)
⚔️ 공격 벡터
로컬 권한을 가진 공격자가 configfs를 통해 장치 속성을 동시에 수정하여 레이스 컨디션을 유발
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 null_blk의 속성 저장 로직에 잠금 메커니즘 적용
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인