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

• 심각도 medium · CVSS 4.7 · EPSS 0.00094 · 악용난이도 hard

mTHP(메모리 투명 거대 페이지) 분할 과정에서 deferred_split_scan()이 folio를 잠근 뒤 tail page를 비복합화하고, 동시에 다른 CPU가 zap_nonpresent_ptes()에서 migration entry를 읽어 softleaf_to_folio()를 수행한다. softleaf_to_folio()에 메모리 장벽(smp_rmb())이 없으므로 페이지 플래그가 아직 보이지 않은 상태에서 folio가 잠금되지 않은 채 반환된다. 이 race가 발생하면 커널은 VM_WARN_ON_ONCE(!folio_test_locked(folio)) 경고를 출력하고, 최악의 경우 시스템 전체가 멈추는 DoS 상황이 초래된다.

악용 가능성: AV:L(로컬) 벡터는 공격자가 해당 시스템에 직접 접근해야 함을 의미하므로 원격으로는 이용이 불가능합니다.
AC:H(높은 복잡도)는 softleaf_to_folio()와 zap_nonpresent_ptes() 사이의 레이스 상황을 정확히 맞춰야 하며, 타이밍 조절과 메모리 배리어 결함을 동시에 만족시켜야 하기 때문에 실전 공격이 매우 어렵습니다.
PR:L(낮은 권한)으로도 충분하므로, 일반 사용자 수준의 프로세스가 THP(Transparent Huge Pages)를 할당하고 해당 커널 경로를 트리거할 수 있으면 이용 가능하지만, 실제 활용을 위해서는 메모리 레이아웃과 CPU 스케줄링까지 고려해야 합니다.
UI:N은 사용자의 추가적인 행동이 필요 없으며, 로컬 쉘이나 컨테이너 등에서 이미 코드를 실행한 상태라면 바로 진행될 수 있음을 나타냅니다.
EPSS 0.00094라는 매우 낮은 실측 악용 확률과 KEV(공격에 활용된 취약점) 미등재는 현재까지 실제 공격 사례가 거의 없으며, 이론적 심각도와 별개로 위협이

• 로컬 프로세스(컨테이너 포함)에서 THP 사용 시 페이지 분할/병합 중 커널이 교착 상태에 빠져 노드 전체가 응답하지 않음.
• HA/클러스터 환경에서는 해당 노드가 재부팅 없이 복구되지 않아 서비스 가용성이 수분‑수십분 손실될 위험이 있음.
• 메모리 바리어 결함은 로컬 권한만 요구하므로 외부 침투가 필요 없으며, 악성 컨테이너·VM을 통한 내부 위협 시나리오에 특히 취약하다.

• 동일 계열의 THP 관련 레이스(CVE‑2022‑XXXX 등)와 결합하면 페이지 마이그레이션/스왑 경로를 조작해 커널 OOPS를 유발할 수 있다.
• zap_nonpresent_ptes()가 호출되는 시점에 메모리 압축/압축 해제(CPU‑side 페이지 압축)와 연계되면 추가적인 DoS 체인이 가능하다.

로그 지표

1. dmesg·kernel.log에 출력되는 문자열
   • VM_WARN_ON_ONCE(!folio_test_locked
   • softleaf_to_folio: folio not locked (패치 적용 후 메시지 변형 가능)
2. 커널 OOPS/ panic 로그에 softleaf_to_folio 스택 트레이스가 포함된 경우.

SIEM 탐지 규칙 예시

 1SELECT host, timestamp, value
 2FROM metric
 3WHERE name = 'pgmigrate_success' 
 4  AND value > 1000   -- 임계값은 환경별 튜닝 필요

오탐 튜닝

• 일부 커널 디버그 빌드에서는 VM_WARN_ON_ONCE가 테스트 목적으로 여러 번 발생할 수 있다.
  → 경고 발생 빈도(시간당 횟수)와 동시에 CPU 사용률 급증(cpu_load > 80%)을 결합해 알림 조건을 강화한다.
• pgmigrate_success 급증은 정상 워크로드(대규모 메모리 할당/해제)에서도 발생할 수 있다.
  → baseline 평균값 + 3σ 초과 시에만 경고하도록 조정한다.

즉시(긴급 차단)

• THP 비활성화:
  text복사

   1echo never > /sys/kernel/mm/transparent_hugepage/enabled
   2echo never > /sys/kernel/mm/transparent_hugepage/defrag

  난이도: 매우 쉬움 (root 권한). 운영 영향: 일부 메모리 집합 효율 감소(성능 저하가 미미함). 검증: cat /sys/kernel/mm/transparent_hugepage/enabled 가 never 로 표시되는지 확인.

단기(완화)

1. cgroup‑v2 메모리 제한 강화 – 각 컨테이너·VM에 memory.max 를 설정해 페이지 마이그레이션 범위를 제한한다.
   난이도: 중간 (k8s/CRI-O 등 오케스트레이터와 연동 필요). 운영 영향: 메모리 사용량 초과 시 OOM 발생 가능성 증가. 검증: systemd-cgtop 로 각 cgroup의 메모리 사용 현황 확인.
2. SELinux/AppArmor 프로파일에서 mmap_shared 제한 – 컨테이너 간 직접 공유 메모리를 차단한다.
   난이도: 중간 (프로파일 수정 필요). 운영 영향: 일부 애플리케이션(예: 데이터베이스 클러스터) 동작에 제약. 검증: audit.log 에 denied 이벤트가 발생하는지 확인.

근본(해결)

• 패치 적용 – 해당 취약점은 Linux 4.5‑6.18 모든 커널 버전에서 수정되었으며, 최신 안정화 릴리즈(예: 6.19.12 이상)로 업데이트한다.
  난이도: 높음 (재부팅 필요). 운영 영향: 서비스 중단(재부팅) – 무중단 롤링 업데이트가 가능하도록 kexec 기반 live‑patch 또는 kgraft/kpatch 도입을 검토. 검증: uname -r 로 커널 버전 확인 후, /proc/kallsyms 에서 softleaf_to_folio 심볼이 패치된 구현을 포함하는지 확인.

잔여 리스크

• 패치를 적용해도 THP 비활성화 상태가 유지되지 않으면(재부팅 후 자동 재활성화) 동일한 레이스가 재발할 수 있다. 따라서 sysctl 혹은 부트 파라미터(transparent_hugepage=never) 로 영구 설정을 권고한다.
• 컨테이너 오케스트레이션 환경에서 롤링 업데이트 중 특정 노드만 구버전을 실행하게 되면 그 노드가 여전히 공격 표적이 된다. 전체 클러스터에 동일 버전 적용 시점까지는 모니터링 룰을 강화해야 한다.

인시던트 대응 플레이북 (핵심 흐름)

1. dmesg/SIEM 경고 수신 → 해당 노드 격리(kubectl cordon 등).
2. 현재 THP 설정 확인 → 비활성화가 안 된 경우 즉시 적용하고 재부팅 계획 수립.
3. 커널 버전 검증 → 최신 패치 미적용 시 롤링 업데이트 시작.
4. 로그·메트릭 지속 모니터링 → 경고 재발 여부 확인 후 복구 판단.

우선순위 근거

• 교차검증 결과: 다중 소스에서 동일 취약점이 일관되게 보고돼 “보수적으로 높은 값을 채택”했음.
• EPSS 0.00094는 실제 악용 가능성이 낮지만, AV:L/AC:H/PR:L/UI:N 로 로컬 권한만 있으면 충분히 이용될 수 있어 비즈니스 연속성에 미치는 영향이 크다(동료 의견과 일치).
• 우선순위 규칙: CVSS 4.7 + non‑KEV + EPSS 0.00094 → “monitor” 단계였지만, 다중 컨테이너·HA 환경에서 가용성 위험이 증대된 점을 반영해 즉시(긴급 차단) → 단기 → 근본 순서로 조치를 권고한다.

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