[방어] 분석 — CVE-2025-68371

• 심각도 미상 · CVSS 미상 · EPSS 0.00168 · 악용난이도 hard

smartpqi SCSI 드라이버에서 LUN 리셋 작업이 sdev_destroy()와 동시에 스케줄될 경우, 디바이스 구조체가 해제된 뒤에도 워크큐가 실행되어 UAF가 발생한다. 로컬 사용자는 /sys/block/<dev>/device/delete 와 같은 인터페이스로 디바이스 삭제를 트리거하고, 동시에 sg_io 혹은 iSCSI TMF(예: RESET LUN) 명령을 전송해 레이스 상황을 강제한다. 성공 시 해제된 구조체에 임의 데이터를 재배치할 수 있어 커널 힙 스프레이·코드 실행으로 로컬 권한 상승(LPE) 이 가능하다. 해당 동작은 CAP_SYS_ADMIN 수준 이상의 권한이 필요하지만, 일반 관리자가 실수로 자동화 스크립트를 운영하면 위험에 노출된다.

악용 가능성: 이 취약점은 AV=Local 로, 공격자가 대상 시스템에 로컬 코드를 실행할 수 있어야만 활용 가능합니다. AC=High 인 만큼 LUN‑reset 작업과 sdev_destroy()  사이의 정확한 타이밍을 맞추는 레이스 컨디션을 재현하는 것이 어렵고, 우연히 발생하기 쉽지 않습니다. PR=High (또는 Root) 요구가 있다는 점은 해당 SCSI 디바이스에 대한 ioctl 이나 sg 인터페이스를 이용하려면 관리자 권한이 필요함을 의미합니다. UI=None 이라 사용자의 직접적인 개입 없이 자동으로 진행될 수 있지만, 앞서 언급한 복잡한 동시성 조건 때문에 실전 공격이 제한됩니다. EPSS 값이 0.00168 로 낮지만 완전히 0은 아니므로 실제 환경에서 일부 조직이 우연히 이 레이스를 트리거할 가능성이 존재합니다. KEV에 등재되지 않은 점은 현재까지 광범위하게 악용된 사례가 없음을 보여주지만, 취약점 자체가 커널 수준의 메모리 해제 후 접근을 허

• 커널 패닉 또는 메모리 손상 → 서비스 중단
• 성공적인 UAF 활용 시 공격자는 커널 레벨 루트 권한을 획득하여 전체 시스템 장악, 파일·프로세스·네트워크 전부 제어 가능
• 해당 드라이버가 로드된 스토리지 어레이(예: Dell PowerVault, HPE Smart Array) 서버에서는 서비스 가용성이 크게 저하될 위험이 있다.

스케줄러/워크큐 기반 UAF는 동일 커널 라인에서 발견된 다른 SCSI 드라이버(예: mpt3sas)의 Use‑After‑Free와 연계해 메모리 레이아웃 예측 정확도를 높일 수 있다. 이러한 체인은 기존 힙 스프레이·주소 재사용 기법과 결합돼 권한 상승 성공 확률을 증가시킨다.

로그 지표

• dmesg / kernel.log : "smartpqi" 와 함께 "use after free", "BUG:", "workqueue" 혹은 "device removed" 문자열이 포함된 항목
• audit.log (auditd) : syscall=ioctl 로 /dev/sg* 에 대한 TMF 전송 직후 execve 가 워크큐 실행을 트리거한 경우

SIEM 쿼리 예시

1. text복사

    1index=kernel sourcetype=syslog 
    2message="smartpqi" AND ("use after free" OR "BUG:" OR "workqueue") AND "removed"

2. text복사

    1index=audit sourcetype=auditd 
    2exe="/usr/sbin/sg_reset" AND msg="device delete" | join _time [search index=kernel message="smartpqi.*workqueue"]

3. 정규식 (Splunk, Elastic 등 공통):
   (?i)smartpqi.*\b(use after free|BUG|workqueue).*removed

오탐 튜닝

• 정상적인 디바이스 재스캔 시 발생하는 "smartpqi: device removed" 로그는 event.action="remove" 와 event.outcome="success" 필터를 추가해 제외한다.
• 워크큐가 scheduled 단계만 기록되고 실제 실행(running)이 없을 경우 경고 레벨을 낮추며, workqueue: running 이 포함된 로그에만 심각도 = high 로 상승시킨다.

1. 모듈 언로드 제한 – /etc/modprobe.d/secure-modules.conf 에 install smartpqi /bin/true 를 추가해 일반 관리자가 임의로 언로드·재로드 못하도록 한다.

   • 난이도 : 중간 (파일 편집)
   • 영향 : 기존 운영 절차에 최소한의 변경만 필요
   • 검증 : modprobe -v smartpqi 시 “module is disabled” 메시지 확인

2. 디바이스 삭제 방어 – /etc/udev/rules.d/99-smartpqi.rules 에 ACTION=="remove", KERNEL=="sd*", ENV{SMARTPQI}=1, GOTO="smartpqi_end" 와 같이 차단 규칙을 두어 자동 스크립트가 디바이스를 삭제하지 못하도록 한다.

   • 난이도 : 중간
   • 영향 : 정상적인 물리적 디스크 교체 시 수동 승인 필요

3. 커널 디버그 옵션 – sysctl -w kernel.panic_on_warn=1 와 debug_lockdep=on 을 활성화해 비정상 워크큐 실행 시 즉시 패닉을 유도, 사고 조기 탐지 가능

   • 난이도 : 낮음 (sysctl)
   • 영향 : 디버그 모드에 따른 약간의 성능 저하와 서비스 중단 위험(패닉 발생 시 재부팅 필요)

• 조치: monitor (모니터링)
• 근거: CVSS=미상 · non-KEV · EPSS=0.00168 · exploit=hard · in_scope=None