CVE-2026-98432: a kernel flaw in the TCP handshake, and what our fleet shows

CVE-2026-98432 has been in the kernel CVE list since 15 October 2026, scored CVSS 9.8: a use-after-free in the IPv4 TCP handshake, reachable remotely without authentication. The correction is in the kernel, and distributions are shipping it now. Ubuntu 26.04, which our mail and AI servers run, is still waiting according to Ubuntu's tracker. This post records what the primary sources say, what only a vendor claims, and what we measured on four of our own servers on 2 November.

CVE-2026-98432 is a memory bug in tcp_v4_syn_recv_sock(). A SYN packet with IP options meets a retransmitted SYN, and the kernel reads memory that has already been freed. Kernels since 4.4 are affected. The bug needs neither MPTCP nor a login, only a reachable IPv4 port.

Updated on 5 November 2026: we re-read every source. Corrected are Oracle's rating and the priority of Red Hat's filter rule. Removed are the names attached to the patch and the report, because we could not verify them. New are the table of distributions and the status at Ubuntu's tracker.

What the bug is

When a connection is set up, tcp_v4_syn_recv_sock() hands the request's IP options to the new socket without copying them. If a retransmitted SYN arrives on another CPU, ip_options_build() builds the reply from memory that is being freed at that moment. It is a race between two CPUs. The fix (commit e3f33b0a1d89, in kernel 7.3-rc7 according to the Debian tracker) replaces kfree with kfree_rcu, so the memory stays until nothing points to it. In its post, Anthropic credits the find to its AI model (a vendor claim). We could not check who wrote the patch: git.kernel.org sits behind a bot wall and gave us only the challenge page. The fix has been taken into the stable branches, according to the CVE record with 5.10.272, 6.1.190, 6.12.113, 6.18.56 and 7.2.10, among others.

The trigger is a SYN carrying IP options such as Record Route or Timestamp, sent to any open port. A second path via net.ipv4.tcp_migrate_req=1 or a BPF migration program is off by default, says AlmaLinux. IPv6 is ruled out for the first path, but the commit says a problem in CALIPSO migration remains, with a separate patch to follow. The kernel CNA also describes a remote crash (skb_under_panic) that needs no code execution at all.

MPTCP: the part many summaries weight wrongly

Many summaries centre on MPTCP. The primary sources do not. Neither the commit nor the CVE record mentions it. On 29 October the Go team wrote on oss-security that the bug is not specific to MPTCP and that systems with no MPTCP listeners may be open to similar attacks. Red Hat goes further: RHEL ships with MPTCP switched off and is vulnerable anyway, and a check for MPTCP listeners is no proof of safety. Anthropic chose MPTCP as the route for its exploit. According to the commit and the CVE record, it is no condition of the bug.

That changes our own first measurement. We had found no MPTCP listener on any host and read that as a relief. The reading does not hold, because every IPv4 TCP listener counts.

What is verified and what only a vendor says

Every row comes from the linked vendor pages, read on 5 November 2026. We rebuilt or re-measured none of it.

The exploit claim has exactly one source: the post by the company that found the bug. According to that post, an unreleased internal model wrote the exploit. Anthropic did not publish the kernel version, configuration or code there. Go and Red Hat point to the description without rebuilding it. It need not be false, but we cannot check it. That Amazon rates the attack as harder to reach than the kernel CNA does is a disagreement that a report should not smooth over.

What our four Ubuntu servers show

We run four servers on Ubuntu 26.04: the LiteLLM router, two mail gateways and the TMS web interface. On 2 November 2026 we queried them read-only over SSH. The figures are our own measurement, and the measuring hosts are exactly these four.

The correction is in 7.0.0-43.43, and on 2 November that was not yet in our index. On 5 November Ubuntu's tracker still lists 26.04 as vulnerable ("work in progress" in 7.0.0-43.43). Whether our apt index shows a candidate by now, we did not measure again after 2 November. The hole stays open until Ubuntu ships.

What it looks like from outside, we do not know: whether a SYN with IP options survives the path across the internet and our edge firewall, we did not measure. Network gear often drops such packets, but that is not proof. Also open is whether any of our programs opens an MPTCP listener. According to the Go security team, Go programs enable MPTCP for listen sockets by default on Linux since Go 1.24. We did not record a check with ss -Mlnp.

Who already ships

The table summarises what vendors had published by 5 November 2026. We did not test these kernels.

What we do, and what we have not done yet

We changed nothing on 2 November. A kernel reboot needs sign-off here. The steps ahead:

• Check daily: once linux-image-generic 7.0.0-43.43 appears in the index, install and reboot, starting with the servers where a failure costs least.
• Prepare the filter: Red Hat (RHSB-2026-016) and AlmaLinux publish an nftables rule that drops incoming IPv4 TCP packets carrying IP options (ip protocol tcp ip hdrlength > 5 drop) as an interim measure. Red Hat puts it in a chain with hook input at priority -310, AlmaLinux in prerouting at -300. Both say it lowers the risk and does not rule the bug out. According to AlmaLinux, traffic between containers on the same host can bypass the rule, forwarded packets are dropped as well (so it is off the table on a router), and it disturbs setups that use CIPSO.
• net.mptcp.enabled=0 closes only the demonstrated attack path and, according to Red Hat, affects only newly created sockets, so running services must restart. It is cheap and reversible and does not replace the patch.
• Keep tcp_migrate_req at 0.

How a mid-sized company can set up updates and reboots cleanly is covered in our post on update and reboot routines for small IT teams. Why a single host can hold up a whole patch round is shown by the apt exit 100 case. More texts sit in the security and privacy topic. If you want to hand server and patch operations to someone else, see our IT services.

What stays open

Three things remain open for us. First, the release day of 7.0.0-43. Second, whether Canonical Livepatch covers the fix, since a livepatch would spare the reboot. Third, how much of the exploit claim holds as long as nobody rebuilds it. Our recommendation: install the kernel as soon as Ubuntu ships it, in the next maintenance window with a reboot, and until then put the filter rule only on hosts that are neither routers nor CIPSO users.

Further reading

• CVE record CVE-2026-98432 (kernel CNA, 15 Oct 2026)
• Kernel commit e3f33b0a1d89 (kfree_rcu fix; the page sits behind a bot wall)
• Ubuntu Security Tracker and Debian Security Tracker
• Red Hat RHSB-2026-016, Red Hat security data and the AlmaLinux post with the nftables rules
• Amazon Linux Security Center and Oracle Linux CVE page
• NVD entry via API and CISA KEV catalogue
• oss-security, 29/30 Oct 2026 (Go team on MPTCP)
• Anthropic on the find (vendor claim, 27 Oct 2026)