리눅스 커널의 IPv4 TCP 핸드셰이크 처리 코드에서 원격 use-after-free 취약점이 드러났다. CVE-2026-98432로 지정된 이 결함은 커널 자체 CVE 넘버링 기관(CNA)이 CVSS 3.1 기준 9.8, 즉 '심각' 등급으로 평가했다. 업스트림 안정 커널은 2026년 10월 11일과 15일에 수정본을 배포했고, 대상 버전은 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3이다. 결함 자체는 리눅스 4.4까지 거슬러 올라가므로 사실상 현역 서버 대부분이 영향권에 들어간다.
문제가 심각한 이유는 위치에 있다. 이 버그는 리눅스 서버가 IPv4 TCP 연결을 수락할 때 실행되는 경로, 즉 어떤 애플리케이션도 연결을 보지 못하는 커널 내부 단계에 존재한다. 로그인도 인증도 필요 없이 원격의 접속 상대가 도달할 수 있다는 뜻이다. 컨테이너는 호스트의 커널 위에서 동작하므로 이미지를 새로 받아도 달라지는 것이 없고, 쿠버네티스 노드와 컨테이너 호스트도 똑같이 노출된다. 다만 '첫 번째 이슈'에 한해 IPv6 연결은 영향을 받지 않는다고 수정 커밋은 밝히고 있다.
버그는 어디서 비롯됐나
리눅스는 TCP 연결을 받을 때 반쯤 열린 핸드셰이크를 가벼운 '요청 소켓(request socket)'으로 추적하다가 핸드셰이크가 끝나면 완전한 소켓을 생성한다. 접속 상대의 IPv4 헤더에 옵션이 담겨 있으면 커널은 응답에 되돌려주기 위해 그 옵션을 보관한다. 문제는 커널이 이 저장된 옵션을 새 연결에 넘겨줄 때 복사하지 않고 포인터만 전달한 뒤, 연결이 사라지면 곧바로 메모리를 해제했다는 데 있다. 그 사이 다른 CPU가 핸드셰이크 응답을 만들려고 같은 메모리를 여전히 읽고 있을 수 있다. 해제된 커널 메모리를 읽는 전형적인 use-after-free다. CNA의 평가 노트는 이로 인해 커널 힙 메모리가 상대에게 유출되거나, 커널 쓰기가 범위를 벗어나거나, 장비가 다운될 수 있다고 적는다.
Eric Dumazet의 수정 커밋 'ipv4: free inet_opt and ireq_opt after an RCU grace period'는 두 개의 단순한 kfree() 호출을 kfree_rcu()로 바꿔, 모든 읽기 작업이 끝날 때까지 기다린 뒤 메모리를 해제하도록 했다. 같은 옵션을 교체하는 다른 코드 경로는 이미 이 방식을 쓰고 있었다. 커밋은 요청 소켓 이관(net.ipv4.tcp_migrate_req=1, 또는 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 프로그램) 경로의 동일 문제도 함께 손봤으며, 관련된 IPv6 사례는 별도 패치로 처리한다고 명시했다.
배포판이 문제다
업스트림 수정은 네 줄짜리에 불과하지만, 실무에서 중요한 것은 각 배포판이 자체 버전 번호로 백포트한 커널이다. 10월 29일 오후 8시(CDT) 기준으로 Debian, SUSE Linux Enterprise Server 16.0 및 15 LTSS, Oracle Linux의 UEK 커널, Amazon Linux 2023의 kernel6.12·kernel6.18에는 수정본이 나왔다. 반면 Ubuntu, RHEL(8·9·10), Amazon Linux 2, 그리고 Amazon Linux 2023의 기본 커널에는 아직 반영되지 않았다. 따라서 상태 확인은 업스트림 버전이 아니라 배포판 트래커를 기준으로 해야 한다. 설치된 커널이 실행 중인 커널보다 최신이더라도 재부팅 전에는 수정이 적용되지 않는다는 점도 놓치기 쉽다. 커널 업데이트는 그 커널로 부팅해야 비로소 효력이 생긴다.
흥미로운 지점은 평가의 온도차다. Red Hat은 공격 복잡도를 'High'로 보아 CVSS 8.1로 낮게 매기고 결과를 주로 '다운 또는 잠재적 메모리 손상'으로 설명한다. 그러나 이 취약점을 제보한 Anthropic은 자사 Claude 모델이 '초기 프롬프트 이후' 실제 동작하는 익스플로잇을 작성했으며, 멀티패스 TCP(MPTCP) 리스너가 있는 리눅스 서버에서 자격 증명이나 사용자 상호작용 없이 root 권한으로 임의 명령을 실행했다고 밝혔다. 개념 증명에서는 커널 포인터를 유출하는 데 48분, 셸 명령 실행에 도달하는 데 추가로 5분이 걸렸다고 한다. 경쟁 조건에서 실패해도 시스템 전체가 죽지 않고 핸드셰이크만 실패하므로 공격자가 성공할 때까지 무한정 재시도할 수 있다는 설명은, 공격 복잡도가 높다는 이유로 대응을 미룰 근거가 되지 못한다는 뜻이다.
지금 할 수 있는 것
가장 확실한 조치는 배포판의 수정 커널이 나오는 즉시 설치하고 재부팅하는 것이다. 컨테이너 호스트와 쿠버네티스 노드도 예외가 아니며, 커널을 번들로 제공하는 어플라이언스나 클라우드 이미지는 벤더 업데이트를 받아야 한다. MPTCP 리스너를 가려내려면 컨테이너 내부가 아니라 호스트에서 ss -M를 실행하면 된다. 결과가 비어 있으면 MPTCP 리스너가 없다는 뜻이고, net.mptcp.enabled=1만으로는 리스너가 생기지 않는다. 실제 MPTCP 소켓을 여는 애플리케이션이 있어야 한다.
Red Hat은 별도 완화책을 내놓지 않았다. 다만 CNA 평가 노트가 공격 상대는 SYN에 IPv4 Record Route나 Timestamp 옵션을 실어 보낸다고 했으므로, 정상 TCP 트래픽이 IPv4 옵션을 거의 쓰지 않는다는 점을 활용할 수 있다. nftables에서 'ip hdrlength gt 5'로 20바이트 최소 헤더보다 긴 IPv4 패킷을 떨어뜨리는 규칙은 연결 추적 이전에 동작하고 IPv6나 비TCP 트래픽은 건드리지 않는다. 다만 이는 커널을 고치는 조치가 아니라 재부팅 전까지 버티는 임시방편이며, 실제 익스플로잇에 대한 검증은 이뤄지지 않았다. 에지 방화벽에서 IPv4 옵션 패킷을 차단할 수 있다면 그 뒤의 모든 호스트를 한 번에 보호할 수 있다. 현재 이 CVE는 CISA의 KEV 목록에 올라 있지 않고 공개된 익스플로잇도 확인되지 않았지만, MPTCP 리스너를 인터넷에 노출하지 않고 해당 호스트를 패치 우선순위 최상단에 두는 것이 당장의 합리적 선택이다.