[방어] 분석 — CVE-2026-23113

• 심각도 medium · CVSS 5.5 · EPSS 0.00115 · 악용난이도 hard

본 취약점은 io_uring의 워커 큐(io-wq)가 종료 신호(IO_WQ_BIT_EXIT)를 확인하는 시점이 적절하지 않아 발생합니다.

1. 트리거: 인증된 로컬 사용자가 /dev/msr*와 같이 read_iter()를 지원하지 않는 파일에 대해 매우 큰 크기(예: 2GB)의 읽기 요청을 다수 큐잉합니다.
2. 지연 발생: 커널은 이를 처리하기 위해 loop_rw_iter()를 사용하며, 이 과정에서 데이터 처리 시간이 극도로 길어집니다(사실 근거: 단일 읽기당 약 20초 소요).
3. 상태 고착: 워커 스레드가 루프 내부에서 작업 완료 전까지 종료 플래그를 확인하지 못하므로, 시스템은 uninterruptible sleep 상태에 빠지며 응답 불능 상태가 됩니다.

악용 가능성: 본 취약점의 공격 난이도는 Hard로 평가됩니다. CVSS 벡터상 AV:L 및 PR:L 조건으로 인해, 공격자는 이미 시스템에 로그인하여 낮은 권한을 가진 계정으로 로컬 쉘 접근권을 확보해야만 트리거가 가능합니다. 공격 표면은 Linux 커널의 io_uring 인터페이스와 /dev/msr* 같은 특정 장치 파일의 I/O 요청 처리 루프입니다. 특히 대규모 읽기 작업(loop_rw_iter)을 통해 커널 워커 스레드의 종료 프로세스를 지연시키는 정밀한 타이밍 조작이 필요하므로, 단순한 실행보다는 환경적 조건 충족이 까다롭습니다. EPSS 수치가 0.00115로 매우 낮고 KEV에 등재되지 않은 점은 실제 야생(In-the-wild)에서 이 취약점을 이용한 공격 사례가 거의 없음을 시사합니다. 따라서 이론적인 커널 레벨의 심각성과는 별개로, 실제 악용 가능성은 특정 조건 하에서의 서비스 거부(DoS)나 시스템 불안정 유발 수준으로 제한적일 가능성이 높습니다.

• 가용성 상실 (DoS): 커널 스레드가 블로킹되어 CPU 자원이 점유되거나 시스템 전체가 멈추는 현상이 발생합니다.
• 시스템 행(Hang): 사실 근거에 따라 hung_task_timeout_secs 임계값(기본 120초)을 초과하는 프로세스 블로킹이 발생하여 커널 패닉 또는 서비스 중단으로 이어집니다.

• 패턴: 로컬 권한 사용자가 커널 리소스의 비효율적인 처리 루프를 이용하여 시스템 가용성을 해치는 Local DoS 패턴입니다.
• 체이닝: 단독으로는 권한 상승(LPE)이 불가능하나, 다른 취약점과 결합하여 특정 보안 모니터링 프로세스를 무력화하는 용도로 사용될 가능성이 추정됩니다.

본 취약점은 커널 내부 루프에서 발생하므로 애플리케이션 로그보다는 시스템 커널 로그 및 성능 지표 모니터링이 핵심입니다.

1. 커널 로그 패턴 탐지 (SIEM/Log Analysis)

• 로그 위치: /var/log/syslog, dmesg
• 탐지 패턴: blocked for more than [N] seconds 문구와 함께 io-wq 또는 syz 관련 태스크가 언급되는지 확인합니다.
• 정규식 예시: INFO: task .* blocked for more than \d+ seconds.*Blocked by .*

2. SIEM 탐지 쿼리 (의사코드)

 1SELECT timestamp, hostname, message 
 2FROM kernel_logs 
 3WHERE (message LIKE '%blocked for more than%' AND message LIKE '%io-wq%')
 4OR (message LIKE '%INFO: task%' AND message LIKE '%uninterruptible sleep%')
 5THRESHOLD: 동일 호스트에서 5분 내 3회 이상 발생 시 Alert

3. 시스템 메트릭 탐지

• 지표: Load Average 급증 및 D state(Uninterruptible sleep) 프로세스 수 증가 모니터링.
• 조건: ps -eo state,pid,cmd | grep '^D' 결과가 비정상적으로 증가하고, 해당 프로세스가 io_uring 관련 시스템 콜을 호출 중인지 확인.

오탐 튜닝 및 주의사항

• 대용량 I/O 작업이 빈번한 DB 서버나 백업 서버에서는 정상적인 D state 발생 가능성이 높습니다. /dev/msr*와 같은 특수 장치 파일 접근과 결합된 패턴인지 확인하여 정밀도를 높여야 합니다.

다중 소스 교차검증 결과 일관성이 확인되었으며, EPSS(0.00115) 및 악용 난이도(Hard)를 고려할 때 우선순위는 monitor로 결정되었습니다. 하지만 영향 범위가 광범위하므로 다음 조치를 권고합니다.

즉시 (긴급 차단)

• 조치: 비특권 사용자의 io_uring 사용 제한 (sysctl 설정)
• 명령어: sysctl -w kernel.io_uring_disabled=2 (또는 1)
• 난이도/영향: 낮음 / io_uring을 사용하는 최신 애플리케이션의 성능 저하 또는 동작 불가 가능성 있음.
• 검증: 비특권 계정에서 io_uring_setup 시스템 콜 호출 시 EPERM 반환 확인.

단기 (완화)

• 조치: /dev/msr* 등 취약점 트리거에 사용되는 특수 장치 파일의 접근 권한(ACL) 강화.
• 난이도/영향: 보통 / 특정 하드웨어 진단 도구의 작동 불능 가능성 있음.
• 검증: ls -l /dev/msr*를 통해 일반 사용자 읽기 권한 제거 확인.

근본 (해결)

• 조치: 영향받는 커널 버전(5.12.1~6.18.8 범위 내)을 패치된 최신 안정 버전으로 업데이트.
• 난이도/영향: 높음 / 커널 업데이트 후 시스템 리부팅 필수, 가용성 일시 중단.
• 검증: uname -r로 업데이트된 커널 버전 확인 및 벤더 제공 보안 패치 내역 대조.

잔여 리스크: 패치 후에도 유사한 로직(루프 내 종료 플래그 미확인)을 가진 다른 커널 서브시스템에서 동일한 DoS 패턴이 발생할 가능성이 존재합니다.

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