CVE-2026-98432 분석 — Linux IPv4 TCP Use-After-Free와 커널 패치 대응

기준 시각: 2026-11-02 18:24 KST. Atlas의 취약점 분석을 출발점으로 CVE 기록, Linux upstream 수정 커밋, Red Hat·Ubuntu·Oracle·Amazon Linux 자료를 대조했다. 공격 코드나 재현 절차는 포함하지 않고, 영향 범위와 방어적 점검·패치 원칙에 집중한다.

결론

CVE-2026-98432는 취약한 Linux 커널의 IPv4 TCP 연결 처리에서 발생하는 Use-After-Free(UAF) 취약점으로, 원격 비인증 공격자가 정교한 타이밍의 요청으로 커널 충돌·메모리 손상 등을 유발할 수 있으므로 커널 공급업체 업데이트를 우선 적용해야 한다. CVE 기록과 배포판별 평가는 서로 다를 수 있어, upstream 버전 숫자만 보지 말고 실제 배포판 패키지 상태와 재부팅 여부를 확인해야 한다.[1][2][3]

1. 취약점 핵심 정보

항목	내용
CVE	CVE-2026-98432
대상	Linux IPv4 TCP 네트워크 스택
유형	IPv4 option 데이터의 Use-After-Free race
공격 조건	원격 네트워크 요청, 인증·사용자 상호작용 불필요로 평가됨
주요 영향	커널 충돌·서비스 거부, 메모리 손상 가능성
upstream 수정	kfree()를 RCU 지연 해제인 kfree_rcu()로 변경
상태 판단	배포판별 보안 공지·패키지 버전·실행 중 커널을 함께 확인

CVE 설명은 재전송된 TCP 연결 요청 또는 socket migration을 동시에 처리하는 과정에서 socket option이 아직 사용 중인데 해제될 수 있다고 설명한다.[1] Red Hat은 IPv4 TCP가 활성화된 취약 커널에서 원격 비인증 공격자가 race condition을 유발할 수 있다고 평가하며, 외부 TCP 연결을 받는 시스템이 직접적인 노출면이라고 안내한다.[3]

2. 문제가 발생하는 흐름

TCP 연결이 완성되기 전 Linux는 request socket으로 연결 상태를 관리한다. IPv4 헤더 option이 있으면 관련 데이터가 request socket에 저장되고, 연결이 진행되면서 child socket으로 소유권이 이동한다.[2]

문제는 이 데이터가 여러 실행 흐름에서 읽힐 수 있는 동안 일반 kfree()로 해제될 수 있다는 점이다.

IPv4 TCP 요청
  → request socket에 IPv4 option 저장
  → 연결 완료 과정에서 child socket으로 전달
  → 다른 CPU가 재전송 SYNACK 경로에서 option 읽기
  → child/request socket 정리 과정에서 메모리 해제
  → 해제된 메모리 접근 가능성(UAF)

Oracle의 기술 설명은 tcp_v4_syn_recv_sock()이 option 포인터를 복사하지 않고 전달하고, 다른 CPU가 SYNACK를 만들며 같은 데이터를 읽는 경쟁 조건을 설명한다.[2] 이 글은 취약점 원리 이해를 위한 방어적 요약이며, 실제 트리거·익스플로잇 코드는 재현하지 않는다.

3. upstream 수정의 의미

Linux upstream 수정 커밋은 다음 두 경로의 일반 해제를 RCU grace period 이후 해제로 바꾼다.[4]

- kfree(...inet_opt...);
+ kfree_rcu(...inet_opt..., rcu);

- kfree(...ireq_opt...);
+ kfree_rcu(...ireq_opt..., rcu);

kfree_rcu()는 동시 읽기 가능성이 있는 동안 메모리를 즉시 반환하지 않고, RCU 독자가 끝날 수 있는 grace period를 기다린 뒤 해제한다. 즉, 수정의 핵심은 기능을 새로 추가하는 것이 아니라 공유·동시 접근 데이터의 수명 관리와 해제 시점을 맞추는 것이다.[2][4]

이 수정은 두 파일의 해제 경로를 바꾼 작은 패치지만, 패치가 작다는 이유로 위험도가 낮다고 판단하면 안 된다. 취약점은 애플리케이션 코드보다 먼저 커널의 TCP handshake 경로에서 발생할 수 있기 때문이다.

4. 영향받을 수 있는 시스템

Atlas 분석과 공급업체 자료를 종합하면, 취약한 커널에서 IPv4 TCP 연결을 받는 Linux 호스트가 우선 점검 대상이다.[3][5]

• 인터넷에 노출된 Linux 웹·SSH·데이터베이스 서버
• 로드밸런서·방화벽·프록시 등 inbound TCP를 받는 장비
• Kubernetes 노드와 컨테이너 호스트
• 클라우드 VM과 베어메탈 서버
• TCP listener를 제공하는 내부 서비스

컨테이너 이미지를 새로 배포하는 것만으로는 호스트 커널이 바뀌지 않는다. 컨테이너는 호스트 커널을 공유하므로, 컨테이너 호스트와 Kubernetes 노드는 노드 OS의 실제 실행 커널을 확인해야 한다.

IPv6의 첫 번째 문제 경로는 IPv4와 동일하게 적용되지 않는다고 upstream 설명에 기록돼 있다. 그러나 이는 시스템 전체가 안전하다는 뜻이 아니다. IPv4 TCP listener와 배포판별 backport 상태를 따로 확인해야 한다.[2]

5. CVSS와 공급업체 평가가 다른 이유

CVE·배포판별 평가에는 차이가 있다.

• Linux/CNA 및 일부 공급업체: CVSS 3.1 9.8 Critical
• Red Hat: Critical, 9.8
• Ubuntu: High로 표시되는 평가와 패치 상태 페이지 제공
• Oracle·Amazon Linux: Important, CVSS 3.1 8.1

Amazon Linux는 정교한 타이밍이 필요한 원격 공격으로 평가하며 8.1을 제시한다.[5] Oracle도 CVSS 3.1 8.1과 Important를 표시한다.[6] 이 차이는 취약점 자체가 여러 개라는 뜻이 아니라, 공격 복잡도·영향·배포판의 실행 조건을 각 공급업체가 다르게 평가할 수 있음을 의미한다.

운영자는 가장 낮은 점수만 선택해 위험을 축소하지 말고 다음을 기준으로 우선순위를 정해야 한다.

인터넷 노출 여부
+ inbound IPv4 TCP 여부
+ 실행 중 커널의 취약·수정 상태
+ 재부팅 필요 여부
+ 중요 서비스·노드 역할
+ 공급업체의 긴급도

6. 배포판별 대응 원칙

Ubuntu

Ubuntu 보안 페이지는 CVE 상태, 패치 상세, 릴리스별 패키지 상태를 제공한다. 패키지 상태가 Not in release, Needs-triage, In progress 등으로 보일 수 있으므로, 단순히 upstream 수정 커밋이 존재한다는 이유로 Ubuntu 패치 완료를 가정하면 안 된다.[7]

RHEL·OpenShift

Red Hat은 RHEL 8·9·10과 RHEL CoreOS를 포함한 제품군의 기반 커널을 확인하라고 안내한다. 네트워크 필터링은 노출을 줄일 수 있지만 완전한 해결책이 아니며, 보안 업데이트 적용이 최종 대응이라고 명시한다.[3]

Debian·Oracle·Amazon Linux 등

Debian·Oracle·Amazon Linux는 각각 고유한 패키지 버전과 advisory를 제공한다. upstream 6.6.159 같은 숫자와 배포판 패키지 버전을 직접 일대일 비교하지 말고, 각 배포판 tracker와 설치된 패키지 changelog를 기준으로 판단해야 한다.[5][6][1]

7. 방어적 점검 체크리스트

7.1 실행 중 커널 확인

uname -r
uname -v

배포판 패키지와 실행 중 커널이 다를 수 있다. 업데이트를 설치했지만 재부팅하지 않았다면, 디스크에는 수정된 커널이 있어도 실행 중인 커널은 여전히 취약할 수 있다.

7.2 패키지·재부팅 상태 확인

# Debian / Ubuntu
apt policy linux-image-generic
needrestart -r 2>/dev/null || true

# RHEL 계열
rpm -q kernel
needs-restarting -r 2>/dev/null || true

명령 출력은 배포판·패키지 구성에 따라 다르므로, 위 명령의 종료 코드만으로 보안 패치 완료를 판정하지 않는다. 실행 중 커널, 설치된 최신 커널, vendor advisory, 재부팅 결과를 함께 기록한다.

7.3 Kubernetes 노드

kubectl get nodes -o wide
kubectl get nodes -o custom-columns=NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage

이 명령은 상태 조회용이다. 노드 drain·reboot·rollout은 서비스 영향이 있으므로 유지보수 창과 별도 승인이 필요하다. 노드 커널이 수정됐는지 확인한 뒤, workload 가용성·PDB·대체 노드·재부팅 순서를 계획해야 한다.

8. 아직 패치할 수 없을 때

Red Hat은 IPv4 header option을 포함한 inbound TCP packet을 nftables로 필터링하는 완화책을 안내한다. 이 방법은 노출을 줄일 수 있지만 필요한 트래픽을 차단할 수 있고, 커널 패치를 대체하지 못한다.[3]

예시 규칙은 공급업체 문서를 그대로 검토하고, 반드시 비운영 환경에서 영향 테스트 후 적용해야 한다.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

운영 적용 전 확인할 항목:

• 기존 nftables/iptables 정책과 우선순위 충돌
• 특정 네트워크 장비·레거시 서비스의 IPv4 option 사용 여부
• 모니터링·관리망·클러스터 내부 통신 영향
• rule hit counter와 drop 로그
• rollback 명령과 승인자

필터링은 임시 방어이며, 공식 패치 적용 후에는 임시 규칙의 필요성과 운영 영향을 재평가해야 한다.[3]

9. 패치 후 검증

패치 성공은 apt upgrade 또는 dnf update가 성공했다는 메시지만으로 판정하지 않는다.

advisory 확인
  → 패키지 업데이트
  → 재부팅 필요 여부 확인
  → 유지보수 창 재부팅
  → uname -r read-back
  → 서비스·노드 Ready 확인
  → 로그·모니터링·inbound TCP 정상성 확인

검증 증거는 다음처럼 남긴다.

• 호스트명 대신 자산 식별자와 점검 시각
• 실행 전·후 kernel release
• 패키지 버전과 vendor advisory
• 재부팅 시각·부팅 성공 여부
• Kubernetes 노드 Ready와 workload 상태
• nftables 임시 완화 적용·제거 여부
• 스캔 도구의 재검사 결과

취약점 스캐너가 0 findings를 반환해도 실제로 수정된 커널이 실행 중인지 별도 확인해야 한다. 반대로 재부팅 직후 서비스가 정상 응답한다고 패치가 완료됐다고 단정하지 말고 kernel read-back을 남겨야 한다.

10. 운영 판단

상태	판정	조치
취약 커널 실행 중·인터넷 inbound IPv4 TCP	FAIL	긴급 패치·재부팅 계획, 필요 시 임시 필터
수정 패키지 설치·구커널 실행 중	WARN	유지보수 창 내 재부팅, 실행 커널 재확인
수정 커널 실행·서비스 정상·vendor advisory 일치	PASS	증거 보존·모니터링·잔여 자산 확인
패키지 상태·실행 커널·backport 여부 불명확	UNVERIFIED	vendor tracker와 호스트 read-back 재수집
컨테이너 이미지만 교체·호스트 커널 미확인	UNVERIFIED	노드 OS 커널을 직접 확인

확인된 사실·해석·미확인

• 확인된 사실: CVE-2026-98432는 Linux IPv4 TCP 처리 중 socket option 수명과 동시 접근이 충돌하는 UAF로 설명된다.[1][2]
• 확인된 사실: upstream 수정은 inet_opt와 ireq_opt 해제를 kfree_rcu()로 변경한다.[4]
• 확인된 사실: Red Hat은 원격 비인증 공격 가능성과 inbound TCP 시스템의 직접 노출을 설명하고, 패치를 완전한 해결책으로 제시한다.[3]
• 확인된 사실: Ubuntu·Oracle·Amazon Linux 등은 upstream과 다른 패키지 버전·상태·심각도 정보를 제공한다.[5][6][7]
• 해석: 이 취약점의 운영 우선순위는 CVSS 숫자 하나보다 인터넷 노출·실행 커널·재부팅 상태·배포판 advisory를 결합해 정해야 한다.
• 미확인: 사용자의 각 노드가 취약한지, 수정 커널을 실행 중인지, MPTCP listener가 있는지, 실제 exploit 시도가 있었는지는 현재 환경을 직접 점검하지 않았으므로 판정하지 않는다.

참고 자료

[1] CVE Record — CVE-2026-98432

[2] Oracle Linux — CVE-2026-98432 technical description

[3] Red Hat — RHSB-2026-016

[4] Linux upstream commit — free IPv4 options after an RCU grace period

[5] Amazon Linux — CVE-2026-98432

[6] Oracle Linux CVE repository — CVE-2026-98432

[7] Ubuntu Security — CVE-2026-98432

※ 이 글은 방어적 취약점 분석이다. 실제 패치·완화 적용은 운영 환경의 배포판 advisory, 변경 승인, 유지보수 창, 서비스 영향 검토를 거쳐야 한다.

Sources

[1] https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf [2] https://www.cve.org/CVERecord?id=CVE-2026-98432 [3] https://linux.oracle.com/cve/CVE-2026-98432.html [4] https://access.redhat.com/security/vulnerabilities/RHSB-2026-016 [5] https://github.com/torvalds/linux/commit/e3f33b0a1d89d738e2b913dab519226eaf76e15b [6] https://explore.alas.aws.amazon.com/CVE-2026-98432.html [7] https://ubuntu.com/security/CVE-2026-98432