[단독방어] 분석 — CVE-2025-38322

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

• 발생 조건: perf/x86/intel 서브시스템이 E‑core(예: RaptorLake)에서 icl_update_topdown_event()를 호출할 때 발생합니다.
• 취약점 원인: 커밋 f9bdf1f95339에서 is_topdown_event()가 잘못 사용되어, 실제로 top‑down 카운트 기능을 지원하지 않는 CPU에서도 해당 함수가 실행됩니다.
• 결과: native_read_pmc 에서 일반 보호 오류(General Protection Fault)가 발생하고, 커널 OOPS 로 이어져 하드 락업(Hard lockup) 상태에 빠집니다.

악용 가능성: 이 취약점은 AV:L/AC:L/PR:L/UI:N 벡터가 의미하듯, 공격자는 로컬 시스템에 직접 접근하고 복잡도가 낮으며 권한이 제한된(일반 사용자) 상태에서도 추가적인 사용자 조작 없이 악용할 수 있습니다. 그러나 실제로는 EPSS = 0.00158 로 매우 낮은 확률이지만 완전히 배제되지 않는 수준이며, KEV에 등재되지 않은 점을 고려하면 현재까지 광범위하게 조직화된 공격 캠페인에서는 활용되지 않았음을 의미합니다. 공격 표면은 Linux 커널의 perf 서브시스템, 특히 icl_update_topdown_event() 함수가 호출되는 경로(예: perf_event_read API)이며, 이는 일반 사용자 권한에서도 perf 도구나 자체 제작 프로그램을 통해 접근이 가능합니다. 다만 이 함수는 RaptorLake · E‑core CPU와 같이 해당 성능 카운터를 지원하지 않는 특정 하드웨어에서만 비정상적인 동작(하드 락업)을 일으키므로, 공격 성공 조건은 제한된 하드웨어 모델과 커널 버전이 전제됩니다. 따라서 공격 난이도는 ‘hard’ 로 평가되지만, 로컬 권한만으로도 트리거가 가능하고 특정 환경에 국한되는 점을 고려하면, 실제 악용 가능성은 낮으면서도 존재하는 위험 요소로 인식해야 합니다.

• 시스템 전체가 멈추는 하드 락업이 발생하여 서비스 가용성이 0%가 됩니다.
• 해당 현상은 루트 권한이 없는 일반 사용자도 perf 이벤트를 열어 시도할 경우 트리거될 수 있어, 다중 사용자가 존재하는 서버·클라우드 환경에서 광범위하게 영향을 미칠 가능성이 있습니다.

• 추정: 유사한 CPU‑특화 PMU(Performance Monitoring Unit) 검증 오류가 다른 아키텍처에서도 발견될 경우, 동일한 is_topdown_event ↔︎ is_topdown_count 혼동 패턴을 이용해 커널 OOPS 를 유발할 수 있습니다.
• 추정: 이와 연계된 공격자는 커널 로그를 조작하거나 시스템 재부팅 없이 지속적인 서비스 거부(DoS)를 목표로 할 수 있습니다.

• 로그 지표

  • dmesg / kernel.log에 기록되는 OOPS 메시지 중 다음 필드가 포함될 경우:
    • RIP: *native_read_pmc*
    • Call Trace: 라인에 icl_update_topdown_event 가 존재
    • 오류 주소 패턴 0xffff[89a-f]{12} (일반 보호 오류)

• SIEM 쿼리 예시 (Elastic Stack 기준)

  sql복사

   1SELECT *
   2FROM syslog
   3WHERE message LIKE '%RIP: *native_read_pmc*%'
   4  AND message LIKE '%icl_update_topdown_event%';

  • 조건 설명: native_read_pmc 호출과 icl_update_topdown_event가 동시에 나타나는 로그만 매치 → 오탐 최소화.

• 정규식 탐지 예시 (Splunk)

  text복사

   1^.*RIP:\s+0x[0-9a-f]+.*native_read_pmc.*\n.*Call Trace:.*icl_update_topdown_event.*

  • 오탐 시나리오: 정상적인 perf 테스트 중 native_read_pmc 가 호출될 수 있으므로, 반드시 icl_update_topdown_event 라인 포함 여부를 확인해야 함.

• 추가 탐지 포인트

  • /proc/kmsg 혹은 perf_event_open 실패 시 반환값 EFAULT/EPERM 로그
  • 시스템 모니터링 툴에서 CPU 23+ (E‑core) 에서 비정상적인 스케줄링 지연 또는 CPU idle 상태 지속 시간 급증 감시

• 즉시(긴급 차단)
  • 모든 E‑core에 대해 Intel PMU를 비활성화:

 1for cpu in $(lscpu | awk '/^CPU\(s\) off/ {next} /^CPU\(s\)/{print $2}'); do
 2    echo 0 > /sys/devices/cpu/$cpu/pmu/enable   # 추정: 실제 경로는 배포판에 따라 다를 수 있음
 3done

• 난이도·영향: 루트 권한 필요, 해당 CPU에서 perf 기반 프로파일링 및 하드웨어 카운터 사용이 완전히 차단되지만 서비스 가용성에는 영향 없음.

• 단기(완화)

  • perf_event_paranoid 값을 2 이상으로 설정하여 비특권 사용자에게 PMU 접근을 제한:

 1sysctl -w kernel.perf_event_paranoid=2

• 배포판 제공 라이브 live‑patch/ksplice 가용 시, 해당 커밋(f9bdf1f95339)을 역으로 적용하는 임시 패치를 적용.

• 난이도·영향: 시스템 재부팅 없이 적용 가능, 성능 측정 도구 사용에 제한 발생(특히 개발/테스트 환경).

• 근본(해결)

  • 취약 코드가 수정된 커널 버전으로 업그레이드:
    • 6.1.150 이상, 6.6.102 이상, 6.12.50 이상, 6.14.3‑6.15.5 등 (각 시리즈의 패치 포함).
  • 배포판(예: Debian)에서 제공하는 보안 업데이트가 발표될 때까지 백포트된 커널 패키지를 적용.
  • 난이도·영향: 재부팅 필요, 전체 시스템 가용성 일시 중단; 그러나 근본적인 취약 제거와 향후 동일 유형 버그 방지에 가장 효과적.

• 검증 방법

  • 업데이트 전/후 dmesg에서 위 탐지 패턴이 사라지는지 확인.
  • perf stat -e intel_pt/... 와 같이 top‑down 이벤트를 명시적으로 실행해도 커널 OOPS 가 발생하지 않는지 테스트.

• 잔여 리스크

  • 패치 적용 전까지는 E‑core에서 모든 perf 기반 하드웨어 카운터가 비활성화된 상태이므로, 해당 기능을 필요로 하는 성능 분석 작업은 대체 방법(소프트웨어 측정)으로 전환해야 함.

• 인시던트 대응 플레이북

  1. OOPS 로그 감지 → native_read_pmc + icl_update_topdown_event 조합 확인.
  2. 즉시 E‑core PMU 비활성화 스크립트 실행.
  3. 시스템 정상화 후, 해당 노드에 최신 커널 패치 적용 계획 수립.
  4. 재발 방지를 위해 perf_event_paranoid 정책을 강화하고, 향후 커널 업데이트 시 관련 커밋 로그 검토.

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