[단독분석] 분석 — CVE-2026-23113

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

io_uring의 작업 큐(io‑wq)에서 IO_WQ_BIT_EXIT 검사가 루프 진입 전으로만 이루어져, 대용량(2 GB~4 KB) /dev/msr* 파일에 대한 read 요청이 남아 있을 경우 loop_rw_iter()가 16 MB씩 읽으며 약 20 초씩 지연됩니다. 이러한 읽기가 다수 쌓이면 작업 큐가 종료되지 않아 커널 스레드가 140 초 이상의 uninterruptible sleep 상태에 머무르게 되고, 시스템 로그에 “task … blocked for more than 143 seconds” 가 기록됩니다.

악용 가능성: 이 취약점은 AV:L·AC:L·PR:L·UI:N 로 평가되었으므로, 공격자는 로컬 시스템에 접근할 수만 있으면 별도의 복잡한 전제조건 없이(예: 특수 권한 상승이나 사용자 입력 없이) 악용이 가능함을 의미합니다. 실제로는 io_uring 워크큐에 대량의 2 GB‑4096 B 읽기 요청을 /dev/msr* 파일 디스크립터와 함께 제출하면, loop_rw_iter() 가 16 MB씩 데이터를 반환하면서 작업 종료가 수십 초까지 지연되어 서비스 거부(DoS) 상태를 유발할 수 있습니다. 이때 공격 표면은 io_uring 인터페이스와 /dev/msr* 파일이며, 해당 파일에 대한 읽기 권한을 가진 로컬 사용자라면(일반적으로 CAP_SYS_RAWIO 권한이 필요하지만 CVSS에서는 “Low”로 평가) 요청을 임의로 큐에 삽입할 수 있습니다. EPSS = 0.00115 라는 매우 낮은 실측 악용 확률과 KEV 미등재는 현재까지 이 취약점이 실제 공격에서 활용된 사례가 거의 없으며, 위협 수준이 이론적 심각도와 별개로 제한적임을 뒷받침합니다. 따라서 난이도는 낮음(Low) 으로 평가되지만, 로컬 권한이 있는 사용자가 다량의 I/O 작업을 조작할 수 있는 환경에서는 서비스 가용성에 영향을 미칠 위험이 존재합니다. 이러한 조건이 충족될 경우, 공격자는 시스템 자원을 고갈시켜 정상적인 io_uring 작업을 방해하는 DoS를 손쉽게 구현할 수 있습니다.

• 기술적 위험:

  • 장시간의 uninterruptible sleep으로 인해 해당 io_uring 워커 스레드가 블록되며, 이는 전체 I/O 서브시스템의 응답성을 저하시켜 서비스 지연 또는 일시적인 중단을 초래할 수 있습니다.
  • 커널이 coredump 상태에 머무르는 경우, 시스템이 정상 복구되지 않을 위험이 존재합니다(핵심 프로세스가 블록될 경우).

• 비즈니스 영향:

  • 가용성 감소: I/O 집약적인 워크로드(예: 고속 스토리지, 데이터베이스)에서 지연이 누적되면 SLA 위반 가능성이 있습니다.
  • 규제·컴플라이언스: 장시간 블록 상태가 로그에 남아 시스템 무결성 감시 체계에서 경고를 발생시키며, 감사 시 “hung‑task” 이슈로 지적될 수 있습니다.
  • 신뢰도 손상: 서비스 지연이 사용자 경험에 직접 영향을 미쳐 기업 이미지가 훼손될 위험이 있습니다.

• 영향 제품·노출 규모:

  • 다중 소스에서 일관성이 확인된 바와 같이, Linux kernel 5.12.1‑6.6.122, 6.7‑6.12.68, 6.13‑6.18.8 전 버전에 적용됩니다(총 8개 이상 커널 라인). 따라서 해당 버전을 운영 중인 모든 서버·컨테이너가 잠재적 노출 대상입니다.

• 동일한 io_uring 워크큐 구조를 이용하는 다른 CVE(예: 과거의 io_uring 경합 문제)와 연계될 경우, 악성 코드가 고빈도 I/O 요청을 조작해 의도적으로 시스템을 ‘hang’ 상태로 만들 수 있습니다. 현재 확인된 직접적인 체이닝 사례는 없습니다.

• 커널 로그(dmesg, /var/log/kern.log)에 “INFO: task … blocked for more than [0‑9]+ seconds.” 가 반복적으로 나타나는 경우.
• cat /proc/sys/kernel/hung_task_timeout_secs 값이 기본(140) 이상이며, 해당 시간 초과 시 경고가 발생하는지 모니터링.
• /dev/msr* 파일에 대한 대용량 read 요청이 io_uring을 통해 수행되는 트레이스(tracepoints: sys_enter_io_uring_setup, sys_exit_io_uring_register)를 감시하면 의심 활동을 포착할 수 있습니다.

• 즉시 조치:

  • echo 0 > /proc/sys/kernel/hung_task_timeout_secs 로 경고 메시지를 일시적으로 비활성화하여 운영 혼선을 줄이되, 근본 원인 분석은 반드시 진행하십시오.
  • /dev/msr*에 대한 대용량 read를 io_uring으로 수행하지 않도록 애플리케이션을 수정하거나 io_uring_register_buffers 사용을 제한하십시오.

• 근본 해결:

  • 다중 소스에서 일관성이 확인된 패치를 포함하는 최신 Linux kernel(5.12.1‑6.18.8 이후)으로 업그레이드합니다.
  • 커널 업데이트가 불가능한 경우, 해당 워크로드를 io_uring 비활성화 옵션(io_uring_setup 호출 시 IORING_SETUP_SQPOLL 등 사용 금지)이나 cgroup 제한을 통해 차단하십시오.

• 추가 권고:

  • 시스템 모니터링 툴에 위의 “hung‑task” 로그 패턴을 추가하고, 장시간 블록 상태가 감지되면 자동 알림을 설정하십시오.
  • EPSS 0.00115와 CVSS 5.5를 고려하여 현재는 monitor 수준으로 우선순위를 지정하였으나(다중 소스 교차검증·실측 악용예측·우선순위 결정에 근거), 패치 적용이 가능한 경우 즉시 배포하는 것이 권장됩니다.

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