Linux's October 2026 TCP Use-After-Free: CVE-2026-98432

extract

Overview Linux's stable kernels shipped a fix on October 11 and 15, 2026 for CVE-2026-98432, a use-after-free in the IPv4 TCP handshake that a remote, unauthenticated peer can reach. The kernel's own CVE Numbering Authority (CNA) scores it CVSS 3.1 9.8, Critical. The fixed releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3, and the bug goes back to Linux 4.4. The upstream fix is a four-line change, but most servers run a distribution's kernel, and as of 5:15 PM CDT, October 31, Ubuntu's tracker still reads "Vulnerable" for its kernel on every release, and Red Hat, which now rates the bug Critical too, lists RHEL 8, 9, and 10 as affected with no fix. Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials. Go programs open those listeners by default, per the Go Security Team. See the timeline. Key facts Who is affected Any Linux kernel from 4.4 on that lacks the fix, whether it serves the network directly or hosts containers: a container runs on the host's kernel, so a new image doesn't change anything. IPv6 connections aren't affected by the main issue; the commit says "IPv6 is not affected by the first issue." Distribution status Distribution kernels carry backported fixes under their own version numbers, so check the tracker, not the upstream number. As of 5:15 PM CDT, October 31: - Ubuntu: the tracker lists the linux package as "Vulnerable" on every release. On 26.10, 26.04, 24.04, and 22.04 it adds "work in progress" in 7.3.0-10.10, 7.0.0-43.43, 6.8.0-149.149, and 5.15.0-203.213; 20.04, 18.04, and 16.04 show only "Vulnerable." Many cloud and hardware-enablement kernels are listed the same way, and no Ubuntu Security Notice has been published. - Red Hat: rated Critical, CVSS 3.1 9.8, since October 30. RHEL 8, 9, and 10 and OpenShift Container Platform 4 and 5 are listed as affected, with no fix; RHEL 6 and 7 aren't affected (CVE page). Its bulletin, RHSB-2026-016, says "Red Hat is expediting the release of fixes," gives an nftables mitigation (compared below), and says any product that relies on the RHEL kernel, including RHEL CoreOS, "is also potentially impacted." - AlmaLinux: fixed kernels for AlmaLinux 8, 9, and 10 (kernel-4.18.0-553.180.2.el8_10, kernel-5.14.0-687.61.2.el9_8, and kernel-6.12.0-211.69.2.el10_2) have been in its testing repository since October 30, ahead of RHEL. AlmaLinux will move them to production after community testing, and its errata don't list them yet (announcement). - Debian: fixed in 12 "bookworm" (6.1.190-1, DLA-4841-1, and linux-6.12 6.12.113-1~deb12u1, DLA-4850-1), 13 "trixie" (6.12.113-1, DSA-6568-1), and unstable (tracker). - SUSE: rated important. SUSE Linux Enterprise Server 16.0 (kernel-default 6.12.0-160000.40.1) and the 15 SP4, SP5, and SP6 LTSS kernels are fixed; 15 SP7 is in progress. openSUSE Leap 16.0 is fixed, and Leap 15.6 is listed as affected (CVE page). - Oracle Linux: rated Important, CVSS 3.1 8.1. Unbreakable Enterprise Kernel (UEK) errata for Oracle Linux 7, 8, 9, and 10 came out October 16: ELSA-2026-500397, ELSA-2026-500398, and ELSA-2026-500399 (CVE page). The page lists only the UEK kernels. - Amazon Linux: rated Important, CVSS 3.1 8.1, and every kernel is fixed. On Amazon Linux 2023, the default kernel (ALAS2023-2026-3365, October 30), kernel6.12 (ALAS2023-2026-3335, October 29), and kernel6.18 (ALAS2023-2026-3251, October 24). On Amazon Linux 2, the core kernel (ALAS2-2026-4065) and the 5.4, 5.10, and 5.15 Extras kernels (ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137, and ALAS2KERNEL-5.15-2026-120), all October 30 (CVE page). How the vulnerability works When a Linux server accepts a TCP connection, the kernel tracks the half-open handshake in a lightweight "request socket," then creates a full socket once the handshake completes. If the connecting peer's IPv4 header carried options, the kernel keeps them to echo in its replies. The bug: the kernel handed those saved options from the request socket to the new connection without copying them, then freed them immediately when the connection went away, while another CPU could still be reading them to build a handshake reply. Reading freed kernel memory is a use-after-free. The peer needs no login, and it all happens inside the kernel's handshake handling, before any application code runs. The CNA's scoring notes say the stale data can leak kernel heap memory back to the peer, steer kernel writes out of bounds, or crash the machine. Anthropic says a lost race "only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." The fix Eric Dumazet's commit, "ipv4: free inet_opt and ireq_opt after an RCU grace period," changes two plain kfree() calls to kfree_rcu(), which waits until every reader has finished with the memory before freeing it. Other code paths that replace these options already did that. The commit also fixes the same problem in request-socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program), and says a related IPv6 case "will be addressed in a separate patch." Which servers are exposed - Every Linux host that accepts IPv4 TCP connections on an affected kernel: web servers, SSH, databases, load balancers, and Kubernetes nodes. The CNA's notes say the vulnerable path runs "during the TCP handshake, before application authentication." - Hosts with a multipath TCP (MPTCP) listener first. That's the setup Anthropic's working exploit needs: "Linux servers with a multipath TCP listener." Anthropic hasn't said why that listener matters, and the CVE record doesn't mention MPTCP. A server has one only if an application opens an MPTCP socket, and Go programs do by default: the Go Security Team says "as of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux." The default follows the go line in the program's go.mod, and applies only where the kernel allows MPTCP (net.mptcp.enabled = 1, as on the Debian 12 kernel we checked; AlmaLinux says it ships MPTCP off). The Go team adds that "the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks." The check is below. Red Hat now rates it as the CNA does. It raised the bug from Important (8.1) to Critical (9.8) on October 30, citing "the lack of network prerequisites and the potential for severe system instability." Its bulletin says "Systems accepting inbound TCP connections are most directly exposed." How to check your systems Check the kernel Compare the result with your distribution's status above, not with the upstream version. If the installed kernel is newer than the running one, the fix isn't active until you reboot. Run these on container hosts and Kubernetes nodes, not inside containers: a container reports the host's kernel. We ran them on a Debian 12 host and in a Rocky Linux 9 container. Check for multipath TCP listeners ss -M lists only MPTCP sockets, so an empty result means no MPTCP listener. net.mptcp.enabled = 1 alone doesn't create one: an application has to open an MPTCP socket. We tested both with iproute2 6.1 in a Debian 12 container, where ss -Mlnp listed a test MPTCP listener and skipped a plain TCP one beside it. On October 31 it also listed a Go HTTP server whose go.mod says go 1.24, and skipped the same server built with go 1.23. How to fix Update the kernel and reboot Install your distribution's fixed kernel as soon as it ships, then reboot: a kernel update doesn't take effect until the machine boots into it. Reboot container hosts and Kubernetes nodes too. Appliances and cloud images that bundle a kernel need their vendor's update. On Debian, SUSE Linux Enterprise Server 16.0 and the 15 LTSS releases, openSUSE Leap 16.0, Oracle Linux's UEK kernels, and Amazon Linux 2 and 2023, the fix is out. AlmaLinux's is in its testing repository. On Ubuntu and RHEL, it isn't out yet, as of 5:15 PM CDT, October 31. Watch the trackers linked above. Running a self-built kernel? Move to the fixed stable release for its line. If you can't patch yet Red Hat's bulletin and AlmaLinux now publish nftables rules that drop incoming IPv4 TCP packets carrying IP options. Red Hat says its rule "reduces exposure to this vulnerability but cannot fully prevent it." The following is Atlas's interim recommendation, the same rule as AlmaLinux's, based on the CNA's scoring notes, which say the attacking peer supplies IPv4 Record Route or Timestamp options in its SYN. TCP traffic almost never carries IPv4 options legitimately, so dropping TCP packets that have them should cost nothing: ip hdrlength gt 5 matches any IPv4 header longer than the 20-byte minimum, which only options produce. The rule runs before connection tracking and doesn't touch IPv6 or non-TCP traffic. We tested it in a Debian 12 container: it dropped a SYN carrying a Record Route option, and ordinary TCP connections still worked. We haven't tested it against an exploit, and it doesn't fix the kernel. It lasts until reboot, which is fine if the reboot is into a fixed kernel; remove it with nft delete table ip cve_2026_98432. If your edge firewall can drop IPv4 packets with options, doing it there protects every host behind it. If you manage the firewall with iptables, this rule does the same job from the raw table, which also runs before connection tracking: The u32 match reads the IPv4 header-length field, and a value of 6 to 15 means the header carries options. We tested it with iptables 1.8.9, on both its nf_tables and legacy backends, in a Debian 12 container: it dropped a Record Route SYN sent to the host and one routed through it, and ordinary TCP connections still worked. Remove it by running the same command with -D in place of -I; like the nft rule, it lasts until reboot. It needs the kernel's xt_u32 module, which the Debian 12, Ubuntu 22.04 and 24.04, and RHEL 8 kernels include. RHEL 9 and 10 kernels, and their rebuilds, leave it out, so use the nft rule there. Red Hat's rule hooks input; ours hooks prerouting, so it also drops packets the host routes on to containers. On October 31 we tested it against two pairs of network namespaces. It dropped a Record Route SYN routed between one pair, and never saw one bridged between the other, as AlmaLinux warns: "Traffic between containers on the same host may bypass it." AlmaLinux also says not to use it on networks that rely on CIPSO security labels, which travel in IPv4 options. Turn off multipath TCP if you don't use it. That removes the setup Anthropic's exploit needs, though not the bug. AlmaLinux's steps: New MPTCP sockets then fail, and Go programs fall back to plain TCP when they start. The setting is per network namespace, and each new one starts with MPTCP on, so a container keeps it unless you set it there too (Docker: --sysctl net.mptcp.enabled=0). We tested the steps and the Docker flag on October 31. For a single Go program, GODEBUG=multipathtcp=0 in its environment turns the default off, but the Go Security Team calls disabling MPTCP program by program "a fragile mitigation." Until you can patch, keep MPTCP listeners off the internet, and put the hosts that have one at the top of the patch list. Timeline and exploitation status All times are CDT (UTC−5). Exploitation status. Anthropic says Claude wrote the exploit "after initial prompting," that it runs "arbitrary commands as root, without any credentials or user interaction" on servers with a multipath TCP listener, and that in its proof of concept "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution." Anthropic hasn't published the exploit. Its disclosure policy gives developers 90 days to patch and a further 45 days before Anthropic discusses details beyond a public advisory. Red Hat's bulletin now says the bug could be exploited "to trigger remote code execution." By 5:15 PM CDT on October 31, 36 GitHub repositories referenced the CVE. Most describe themselves as audit or mitigation tooling, among them Ansible roles and a livepatch for AlmaLinux and Rocky Linux. At least six say they include a race trigger or a proof of concept for the use-after-free; the first was created at 7:22 PM on October 29, and the latest at 11:04 AM on October 31. The CVE isn't in CISA's Known Exploited Vulnerabilities catalog as of 5:15 PM CDT. We haven't tested any public proof of concept, and we aren't linking them. Updates to this post We'll revise this post and mark it updated when any of these change: fixed kernels from Ubuntu or Red Hat, or AlmaLinux's production release; NVD's analysis; a KEV listing or any report of exploitation; the separate IPv6 fix. - October 31, 5:15 PM CDT: Red Hat raised its rating from Important (8.1) to Critical (9.8) on October 30 and published a mitigation in bulletin RHSB-2026-016, so we replaced its earlier rating and its "no mitigation" statement. Added the Go Security Team's notice that Go programs open MPTCP listeners by default, AlmaLinux's fixed kernels in testing, Amazon Linux's fixes for its remaining kernels, openSUSE Leap 16.0's fix, steps to turn off MPTCP, an iptables version of the interim rule, and the interim rule's limits with bridged container traffic and CIPSO. 36 GitHub repositories now reference the CVE. Ubuntu, Debian, Oracle, NVD's status, and KEV are unchanged, and the stable kernels released October 30 don't include the IPv6 follow-up. - October 29, 8:00 PM CDT: Added Oracle Linux, fixed in its UEK kernels since October 16, and Amazon Linux, fixed in Amazon Linux 2023's 6.12 and 6.18 kernels and pending elsewhere. Eight GitHub repositories now reference the CVE, one describing a race trigger. Ubuntu, Red Hat, Debian, SUSE, NVD, and KEV are unchanged since 11:00 AM, and nothing was corrected. Get help If the hard part is knowing which hosts, nodes, and appliances run which kernel, and which of them can reboot this week, our advisors can help plan it. The bug is reachable through any listening TCP port, so it helps to know which ones the internet can see. Our free external audit checks the domains and public IPs you verify for exposed services, publicly visible software versions with known CVEs, TLS, email security, DNS, and HTTP headers. It's the second Linux kernel fix this month that only takes effect after a reboot. The other, Fragnesia, is being chained with PHP2Shell to get root. Sources - Linux kernel: fix commit e3f33b0 · patch on lore · stable commits for 7.2.10, 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 · kernel.org releases - CVE records: cve.org · NVD - Advisories: Red Hat RHSB-2026-016 · AlmaLinux · Go Security Team, via oss-security · Go's multipathtcp setting - Distributions: Ubuntu · Red Hat · AlmaLinux errata · Debian · SUSE · Oracle Linux · Amazon Linux - Research: Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude · Anthropic's coordinated vulnerability disclosure policy The Atlas security byline: write-ups of vulnerabilities in widely deployed software — what changed, who is exposed, and what to check — verified against primary sources.