CVE-2026-98432의 MPTCP 리스너 조건과 Go·필터·커널 대응의 차이

취약점과 공개된 원격 실행 경로

Ubuntu의 CVE-2026-98432 설명에 따르면, Linux IPv4 TCP 연결 처리 중 요청 소켓의 IP 옵션을 새 연결 소켓에 복사하지 않고 넘긴 뒤 재전송된 SYN에 답하는 CPU가 같은 옵션을 읽을 수 있습니다. 그 사이 새 소켓이 해제되면 커널이 RCU 보호 아래 읽던 메모리를 일반 kfree()로 반환해 use-after-free가 발생합니다. 설명에는 요청 소켓 마이그레이션 과정에서 공유 옵션을 해제하는 유사 경로도 나옵니다.

Anthropic은 2026년 10월 27일 공개한 글에서 공격자가 자격 증명이나 사용자 조작 없이, MPTCP 리스너가 열린 Linux 서버에서 root 명령을 실행하는 exploit을 소개했습니다. The Hacker News도 이 원격 실행 시연의 MPTCP 리스너 조건을 전했고, Go 보안팀은 공개된 exploit이 대상의 MPTCP 리스너 노출을 요구한다고 설명했습니다. Go 보안팀은 동시에 버그 자체는 MPTCP 전용이 아니며 리스너가 없는 시스템도 유사 공격에 취약할 수 있다고 밝혔습니다. 따라서 MPTCP 리스너는 공개 시연의 조건이고, 결함은 IPv4 TCP 처리에 있습니다.

Go 서버의 MPTCP 기본값과 설정

MPTCP는 하나의 TCP 연결에서 여러 네트워크 경로를 활용하게 하는 확장입니다. Linux 커널 문서는 애플리케이션이 소켓을 열 때 MPTCP를 요청해야 한다고 설명합니다. Go 보안팀은 Go 1.24부터 Linux에서 listen 소켓이 MPTCP를 기본 활성화한다고 안내했습니다. 다만 Go 문서에 따르면 실제 기본값은 빌드 도구와 go.mod에 적힌 Go 버전, 명시적인 //go:debug 설정에 따라 달라집니다. 따라서 Go 서버의 버전 숫자만으로 실제 리스너 설정을 단정할 수 없습니다.

Go 보안팀은 GODEBUG=multipathtcp=0을 프로그램 환경에 설정하면 실행 시 MPTCP 기본값을 끄고, 주 모듈의 go.mod에 godebug multipathtcp=0을 넣으면 빌드 시 기본값을 끌 수 있다고 밝혔습니다. net.ListenConfig.SetMultipathTCP 같은 소켓별 설정은 이 값을 덮어씁니다. Go 보안팀은 프로그램별로 MPTCP를 끄는 방식이 취약한 완화책이라고 설명합니다. 노출된 MPTCP 리스너 하나가 남으면 시연된 경로가 유지될 수 있고, 커널 결함도 그대로이므로 팀은 수정 커널 업그레이드를 권고했습니다.

앱 설정·패킷 필터·커널 수정의 역할

Red Hat 보안 공지는 nftables 규칙으로 IP 옵션이 포함된 인바운드 IPv4 TCP 패킷을 걸러 취약 코드 경로에 들어오는 트래픽을 줄이는 방식을 제시했습니다. 규칙은 IPv4 헤더 길이가 기본값보다 긴 패킷을 대상으로 합니다. 일반적인 TCP 옵션은 TCP 헤더에 있으므로 계속 허용됩니다. Red Hat은 이 필터가 노출을 낮추지만 취약점을 완전히 막지는 못하며, 필요한 작업에 지장을 줄 수도 있다고 설명했습니다.

세 대응은 작동 지점이 다릅니다. Go 설정은 애플리케이션의 MPTCP 소켓 기본값을 바꾸고, Red Hat의 필터는 특정 IPv4 패킷을 걸러 노출을 줄입니다. 커널 수정은 inet_opt와 ireq_opt를 해제할 때 kfree_rcu()를 사용해 RCU 독자가 읽기를 마친 뒤 메모리를 반환하도록 바꿉니다. Red Hat은 커널 보안 업데이트를 완전한 해결책으로 제시했습니다.

배포판 패키지에서 확인되는 수정 상태

업스트림 커널에 수정이 들어간 시점과 배포판 사용자가 수정 패키지를 받을 수 있는 시점은 다릅니다. The Hacker News는 2026년 10월 29일 기준으로 Debian·Oracle Linux·SUSE와 Amazon Linux 일부 커널 패키지에 수정이 배포됐고, Ubuntu와 RHEL에는 수정 커널이 없다고 보도했습니다. Ubuntu CVE 페이지는 22.04·24.04·26.04·26.10의 커널을 수정 작업 중으로 표시했습니다. 보도는 10월 30일 업데이트에서 RHEL 8·9·10과 OpenShift 4의 상태가 Fix deferred에서 Affected로 바뀌었다고 덧붙였으며, Ubuntu와 Red Hat은 당시 출시일을 제시하지 않았습니다. 실제 설치 가능 여부는 업스트림 버전이 아니라 배포판의 커널 패키지 상태에 달려 있습니다.