🇰🇷 한글 설명
Linux 커널의 ISCI 드라이버에서 장치 제거 경로 중 Use-After-Free 취약점이 발견되었습니다. 장치 제거 시 인터럽트 핸들러가 완료 태스크릿을 다시 스케줄링할 수 있어, 이미 해제된 메모리 영역에 접근하여 시스템 오류를 유발할 수 있습니다.
💡 쉬운 설명
컴퓨터 부품을 제거하는 과정에서 프로그램이 이미 사라진 부품의 정보를 참조하려고 시도하여 발생하는 오류입니다. 이로 인해 시스템이 갑자기 멈추거나 충돌이 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
scsi: isci: Fix use-after-free in device removal path
The ISCI completion tasklet is initialized in isci_host_alloc()
(drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy
interrupt handlers (drivers/scsi/isci/host.c:223,613).
isci_host_deinit() stops the controller and waits for stop completion,
but it never kills completion_tasklet before teardown continues. A
top-of-function tasklet_kill() is not sufficient here: interrupts are
only disabled when isci_host_stop_complete() runs, so until
wait_for_stop() returns the IRQ handlers can still requeue the
tasklet. The tasklet callback also re-enables interrupts after draining
completions, so killing the tasklet before the source is quiesced leaves
the same race open.
Once wait_for_stop() returns, no further IRQ-driven scheduling can
occur. Kill completion_tasklet there so teardown cannot race a queued
tasklet running on a dead ihost. On remove or unload, the stale callback
can otherwise dereference ihost and touch ihost->smu_registers after the
host lifetime ends.
A UML + KASAN analogue reproduced the failure class both with no
tasklet_kill() and with tasklet_kill() placed before source quiesce, and
stayed clean once the kill happened after quiescing the scheduling
source.
This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in
device removal path"), but ISCI needs the kill after wait_for_stop().
📍 영향받는 시스템
Linux kernel (ISCI driver 사용 환경)
⚔️ 공격 벡터
로컬 공격자가 장치를 제거하거나 드라이버를 언로드하여 메모리 손상 유도
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 패치 버전 이후인지 확인