[방어] 분석 — CVE-2026-31448
Critical ext4 infinite‑loop DoS in Linux kernels 2.6.22.1‑6.19.11 can be temporarily mitigated by mounting affected filesystems with the nodelalloc option and monitored via kernel audit logs for repeated EXT4 allocation failures.
📋 요약
- 심각도 critical · CVSS 9.4 · EPSS 0.00443 · 악용난이도 moderate
🔍 공격 기법
ext4 파일시스템에서 mkdir/mknod 수행 시 논리 블록을 물리 블록에 매핑하는 과정에서 새 extent 삽입이 실패하면(huge_file 비활성화·inode dirty 처리) ext4_ext_map_blocks()는 물리 블록만 회수하고 extent 트리는 정리하지 않는다. 이후 동일 블록이 디렉터리와 xattr 모두에 재사용되어 ext4_xattr_block_set()가 “inserted” 상태에서 무한 루프에 빠진다. 이 루프는 inode 락을 해제하지 못해 커널 스케줄러를 143 초 이상 차단하고, 메타데이터 손상·커널 패닉까지 이어질 수 있다.
악용 가능성: 이 취약점은 AV:N (네트워크를 통해 원격에서 접근 가능)이며, AC:L (공격 복잡도 낮음)으로 평가됩니다. 즉, 공격자는 네트워크 서비스가 ext4 파일시스템을 사용하고 있을 경우 특별한 사전 지식 없이도 악의적인 mkdir/mknod 요청만 전송하면 됩니다. PR:N (특권 요구 없음)과 UI:N (사용자 상호작용 필요 없음) 조합은, 권한이 없는 원격 공격자가 별도의 인증 절차나 사용자 클릭 없이 자동으로 악용할 수 있음을 의미합니다. 그러나 EPSS 값이 0.00443 로 매우 낮고 KEV 목록에 등재되지 않은 점은 현재까지 실제 공격 사례가 거의 없으며, 위협 인식도가 낮다는 실증적 근거를 제공합니다. 공격 표면은 ext4 파일시스템을 백엔드로 사용하는 모든 네트워크 파일 서비스(NFS, Samba, FTP 등)와, 해당 서비스가 디렉터리 생성·노드 생성 요청을 처리하는 엔드포인트(예: mkdir, mknod API)입니다. 따라서 공격자는 이러한 서비스를 통해 임의의 파일시스템 메타데이터를 조작해 동일 물리 블록을 중복 사용하도록 유도함으로써 커널 메모리 오류를 일으킬 수 있습니다. 전체적으로는 원격·무특권·자동화된 공격이 가능하지만, 현재 관측된 악용 빈도가 매우 낮아 moderate 등급으로 평가됩니다.
💥 영향 분석
- 동일 블록이 디렉터리와 xattr에 동시에 매핑돼 메모리 버퍼 충돌 발생
ext4_xattr_block_set()무한 루프로 인한 서비스 거부(DoS), 시스템 응답 지연 ≥ 2 분- 메타데이터 손상 시 파일시스템 전체가 마운트 해제·재부팅 필요, NFS/CIFS와 같은 원격 마운트 서버에서는 전체 서비스 다운 위험
🔗 관련 취약점·체이닝
- ext4 delayed‑allocation(DA) 관련 오류(
EXT4_ALLOC_DA_ALLOC_FAIL)가 선행될 경우 메타데이터 손상이 가중됨 - 동일 파일시스템에서 quota 업데이트 오류와 결합하면 디스크 할당량 초과 상태를 은폐할 수 있음
🔎 탐지
로그 지표
dmesg·kernel.log에 기록되는 EXT4 오류 메시지- 예:
EXT4-fs error (device xxx): ext4_xattr_block_set: inode xxxx locked
- 예:
auditd이벤트EXT4_ALLOC_DA_ALLOC_FAIL(if enabled) 또는syscall=mkdir/mknod가EIO/ENOSPC반환kworker프로세스 CPU 사용량 급증 및blocked for 143 seconds와 같은 스택 트레이스
SIEM 탐지 규칙 예시 (Splunk)
1index=kernel_logs sourcetype="dmesg" 2| regex _raw "EXT4-fs error.*ext4_xattr_block_set.*locked" 3| stats count by host, _time span=1m 4| where count > 3Elastic Kibana 쿼리 예시
1{ 2 "bool": { 3 "must": [ 4 { "match_phrase": { "message": "ext4_xattr_block_set" }}, 5 { "range": { "@timestamp": { "gte": "now-5m" }}} 6 ], 7 "filter": { "script": { "source": "doc['event.count'].value > 2" }} 8 } 9}오탐 튜닝
- 정상적인 EXT4 경고(예:
filesystem full)는 “locked” 문자열이 없으므로 필터링 - 동일 호스트에서 짧은 기간에 다수 발생하는 경우만 알림 (threshold > 3/1 min)
🛡️ 완화 방안
- Delayed Allocation 제한
sysctl -w vm.dirty_ratio=10등으로 dirty 페이지를 제한해 대량 할당을 억제한다.
- 감시 강화
- auditd에
-a exit,always -S mkdir -S mknod -F success!=0규칙 추가하고, 위 탐지 쿼리를 자동 알림 파이프라인에 연동한다.
- auditd에
- 파일시스템 검증
- 정기적으로
fsck.ext4 -n /dev/xxx실행해 메타데이터 손상 여부를 사전 점검한다.
- 정기적으로
- 난이도: 중간 (auditd 규칙·sysctl 적용)
- 운영 영향: 거의 없음, 다만
fsck는 I/O 부하가 일시적으로 증가할 수 있음
⚖️ 위험도 / 우선순위
- 조치: scheduled (이번 주 내)
- 근거: CVSS=9.4 · non-KEV · EPSS=0.00443 · exploit=moderate · in_scope=None