[분석가] 분석 — CVE-2025-71097

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

ip nexthop del 로 삭제된 nexthop 객체가 “dead” 상태가 되지만, 해당 nexthop을 사용한 blackhole 등 오류 라우트는 자동으로 플러시되지 않는다. 남은 오류 라우트가 nexthop 및 관련 디바이스에 대한 참조 카운트를 유지해 메모리 누수를 일으키고, 누적된 참조 수가 임계점에 도달하면 커널이 장치 해제를 기다리며 시스템이 정지한다.

악용 가능성: 이 취약점은 AV:L (로컬 네트워크 스택) 조건에서만 발동되므로 원격 공격자는 직접 이용할 수 없으며, AC:L (낮은 복잡도)와 PR:L (낮은 권한) 때문에 일반 사용자라도 CAP_NET_ADMIN 권한이 있거나 네임스페이스 내에서 ip 명령을 실행할 수 있다면 공격이 가능합니다. UI:N (사용자 상호작용 없음)으로, 악성 스크립트가 자동으로 nexthop 객체를 삭제하고 오류 라우트를 남겨두는 동작만 수행하면 되므로 추가적인 사용자 개입이 필요하지 않습니다. 실제 위험도는 EPSS 0.00114라는 매우 낮은 확률과 KEV(핵심 취약점) 미등재로 확인되며, 이는 현재까지 실증된 악용 사례가 거의 없음을 의미합니다. 공격 표면은 Linux 커널의 fib_table_flush() 함수와 nexthop 객체 관리 로직에 국한되며, 노출되는 엔드포인트는 네트워크 네임스페이스 내에서 ip route/ip nexthop 명령을 사용할 수 있는 인터페이스뿐입니다. 따라서 공격자는 로컬 시스템에 접근해 해당 명령어를 실행할 수 있어야 하며, 권한이 제한된 환경에서는 실제 이용 가능성이 크게 낮아집니다. 전반적으로 이 취약점은 로컬 권한이 확보된 상황에서 DoS (자원 고갈) 형태로 악용될 여지가 있으나, 관측된 실전

• 기술적 위험

  • IPv4 경로에서 오류 라우트(blackhole)가 남아 있어 nexthop 객체 삭제 시 레퍼런스 카운트가 해제되지 않음.
  • 결과적으로 unregister_netdevice: waiting for <dev> to become free. Usage count = N 로그와 함께 커널이 장치 정리를 못하고 멈추어 서비스 중단(Availability Impact = High) 을 초래한다.
  • CVSS 벡터가 C/N/I‑None이므로 기밀성·무결성 손상은 보고되지 않는다.

• 비즈니스 영향

  • 다수의 컨테이너나 가상 머신이 동일 커널을 공유하는 환경에서는 단일 로컬 사용자가 해당 취약점을 이용해 전체 노드를 다운시킬 수 있어 서비스 가용성 SLA 위반 위험이 존재한다.
  • 규제·컴플라이언스 측면에서 직접적인 위반 요소는 없지만, 가용성 저하가 비즈니스 연속성에 미치는 영향은 크다.

• 노출 규모

  • 영향을 받는 커널 버전: 5.3.1‑5.10.248, 5.11‑5.15.198, 5.16‑6.1.160, 6.2‑6.6.120, 6.7‑6.12.64, 6.13‑6.18.4 및 이후 모든 릴리즈.
  • 다수 배포판에 광범위하게 포함되어 있어 공급망 차원의 노출이 크다(품질 신호에서 확인).

• 악용 난이도: EPSS 0.00114와 “hard” 등급을 근거로 실제 악용은 현재 관측되지 않으며, 로컬 권한만으로 트리거 가능하지만 특정 라우트 구성과 삭제 순서가 필요하므로 추정: 공격 구현이 복잡할 수 있다.

IPv6 스택에서는 동일 문제가 보고되지 않았다. 추정: 다른 커널 메모리 관리 버그와 결합될 경우 메모리 고갈을 트리거로 삼아 UAF·RCE 경로로 전이 가능성이 존재한다(실증된 사례는 없음).

• ip route show 로 남은 blackhole 라우트에 nhid <X> 가 표시되는지 정기 점검.
• 커널 로그에서 unregister_netdevice: waiting for .* to become free\. Usage count = 패턴 감시 (grep -i "Usage count =" /var/log/kern.log).
• Netlink 이벤트(RTM_NEWROUTE, RTM_DELNEXTHOP)를 모니터링해 nexthop 삭제 후 오류 라우트가 남아 있는지 확인.

• 즉시 조치: 영향을 받는 커널에 최신 패치를 적용(“ipv4: Fix reference count leak when using error routes with nexthop objects”).
  • ip route flush table <tbl> proto static 혹은 ip route del blackhole … nhid X 로 오류 라우트를 수동 삭제한 뒤 nexthop을 제거.
• 근본 해결: 정기적인 커널 업데이트 정책 강화 및 패치 적용이 어려운 레거시 시스템에서는 주기적 재부팅과 고가용성 클러스터를 활용해 서비스 중단 위험을 최소화한다.
• 추가 방어: 자동화 스크립트(nexthop_cleanup.sh)를 배포해 nexthop 삭제 전 오류 라우트를 모두 정리하도록 운영 환경에 적용.

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