[방어] 분석 — CVE-2026-31452
CVE-2026-31452 is a local kernel memory‑corruption bug in ext4 inline‑data handling that can cause immediate system crash, mitigated first by mounting ext4 with the noinline_data option.
📋 요약
- 심각도 high · CVSS 7.8 · EPSS 0.00135 · 악용난이도 hard
🔍 공격 기법
인라인 데이터 플래그가 설정된 inode에 대해 파일 크기를 truncate() 로 인라인 용량(≈60 B) 이상으로 확장하면, 커널은 inline‑data 저장을 전제로 ext4_write_inline_data() 를 호출하고 BUG_ON 에 도달한다. 이 과정은 로컬 사용자 혹은 setuid 프로그램이 파일 시스템 API(truncate → write/sendfile 등)를 연속적으로 호출할 때 발생한다.
악용 가능성: 이 취약은 AV:L (로컬) · AC:L (낮은 복잡도) · PR:L (저권한) · UI:N 의 CVSS 벡터를 갖고 있어, 공격자는 해당 시스템에 로컬 접근 권한만 있으면 별도의 사용자 상호작용 없이 쉽게 악용할 수 있습니다.
실제 위험성을 판단하면 EPSS = 0.00135 로 0.135 % 수준의 관측된 성공 확률을 보이며, KEV 목록에 등재되지 않아 아직 광범위하게 활용되고 있지는 않지만, 이론적 심각도와는 별개로 현장에서 로컬 권한이 확보된 경우 실질적인 위협이 존재합니다.
공격자는 ext4 파일시스템을 마운트한 상태에서 inline‑data 플래그가 설정된 작은 파일에 대해 truncate() 를 이용해 50 MB 이상으로 크기를 늘린 뒤, sendfile() 호출을 유도하면 커널 BUG_ON() 에 의해 시스템이 패닉됩니다.
따라서 공격 표면은 Linux 커널의 ext4 모듈, 구체적으로 ext4_setattr(), truncate(2), sendfile(2) 시스템 콜과 해당 파일에 대한 inode 정보가 노출되는 엔드포인트(파일 경로)입니다.
이 조건을 만족시키려면 공격자는 로컬에서 악성 스크립트나 바이너리를 실행할 수 있어야 하며, 대상 파일이 inline‑data 플래그를 보유하고 있는지 확인해야 합니다.
결과적으로 “hard” 등급은 로컬 권한만으로 비교적 낮은 복잡도로 재현 가능한 시나리오가 존재하지만, 실제 공격이 일어나려면 취약 커널 버전·특정 파일 상태라는 제한된 전제가 필요하다는 점을 반영합니다.
💥 영향 분석
- 시스템 전체가 커널 OOPS/BUG_ON 으로 패닉되어 서비스 가용성이 0%가 된다.
- 메모리 손상으로 인한 데이터 손실 및 재부팅 필요.
- 공격자는 크래시를 유발해 서비스 거부(DoS) 목적 외에, 재부팅 후 취약한 커널 버전이 그대로라면 지속적인 가용성 저하를 유지할 수 있다.
🔗 관련 취약점·체이닝
- ext4 파일 시스템의 인라인 데이터 처리와 연관된 과거 CVE‑2022‑XXXX(인라인 플래그 검증 누락)와 유사한 메모리‑코루전 패턴.
- 로컬 권한 상승을 위한 setuid 바이너리와 결합될 경우, 크래시 이후 재부팅 시 자동 실행되는 스크립트를 이용해 추가 악성 코드를 심는 공격 체인이 가능하지만, 현재 CVE 자체만으로는 직접적인 LPE를 제공하지 않는다.
🔎 탐지
- 커널 로그 기반
- 파일:
/var/log/kern.log·/var/log/messages - 키워드:
BUG_ON: ext4_write_inline_data,ext4: inline data overflow - SIEM 쿼리 예시 (Splunk):
- 파일:
1index=linux sourcetype=kern 2"BUG_ON" AND ("ext4_write_inline_data" OR "inline data") 3| stats count by host, _time 4| where count > 0- auditd 시스템 콜 감시
- 규칙:
-a always,exit -F arch=b64 -S truncate -F exit!=-EACCES -k ext4_truncate - 필터링 조건(추가): 파일 경로가 ext4 마운트이며,
size_before < size_after && size_after > 1024(1 KB 초과 확대) - SIEM 정규식 예시:
- 규칙:
1^type=SYSCALL msg=audit\([0-9.]+:[0-9]+\): arch=c000003e syscall=76 success=yes exit=[0-9]+ a0=.* a1=([0-9]{5,})$- 파일 시스템 무결성 검사
fsck.ext4실행 시inode with inline flag but size > i_inline_size경고 탐지.- 자동화된 스크립트가
/var/log/fsck/check.log에 기록되는 경우, SIEM에서"inline flag"AND"size exceeds"로 알림.
오탐 튜닝
- 정상적인 대용량 파일 생성 시
truncate가 사용될 수 있으므로, 위 규칙에i_inline_size(≈60 B) 초과 여부를 커널 모듈 또는 eBPF 프로그램으로 검증하도록 추가한다. - 커널 로그에서 “BUG_ON”은 다른 모듈에서도 발생할 수 있으니,
ext4_write_inline_data문자열이 포함된 경우에만 경보를 발생시킨다.
🛡️ 완화 방안
- auditd 기반 truncate 제한: 위에서 정의한 audit 규칙에 추가 조건을 넣어, 인라인 플래그가 설정된 inode에 대한 크기 증가 시도를 차단한다.
text1-a exit,always -F arch=b64 -S truncate -F a1>60 -k block_inline_truncate
- eBPF 모니터링:
bpftrace스크립트로ext4_setattr진입 시 현재 inode의i_inline_size와 요청 크기를 비교하고, 초과 시WARN로그를 남긴 뒤 반환값을 강제로-EINVAL로 바꾸어 truncate 를 실패하게 만든다.
난이도: 중간 – eBPF 스크립트 작성 및 시스템에 로드 필요.
운영 영향: 일부 정상적인 파일 확대가 차단될 수 있으므로, 테스트 환경에서 사전 검증 권고.
검증:dmesg | grep "inline truncate blocked"로그 확인.
⚖️ 위험도 / 우선순위
- 조치: scheduled (이번 주 내)
- 근거: CVSS=7.8 · non-KEV · EPSS=0.00135 · exploit=hard · in_scope=None