CVE-2026-98432 — Linux IPv4 TCP SYN-ACK options use-after-free

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do every Debian suite, Proxmox VE 9’s default kernel, every tracked NixOS ref, Rocky Linux / RHEL 10, 9 and 8, and all three Amazon Linux 2023 kernel streams — install a fixed kernel and reboot into it. The kernels left vulnerable are end-of-life and will never be fixed: upstream 7.1.y, Debian 11 (bullseye), Proxmox VE 8 and PVE 9’s abandoned 6.17 / 6.14 previews, and Amazon Linux 2 — move to a supported release.

Summary

ℹ️ Remote, but it needs IP options. The race only exists for a connection whose SYN carried IPv4 header options, which many networks, firewalls, and cloud fabrics drop outright. A host that never sees IP-options packets from untrusted peers is far less exposed than the CVSS vector suggests; a host that does is exposed on every listening TCP port, before any authentication. Dropping such packets narrows exposure but never fixes the bug: only the kernel backport flips a verdict below.

How the exploitation chain works

When a SYN arrives carrying IPv4 header options, the kernel saves them on the half-open request socket (ireq_opt) so the SYN-ACK can carry them back. With no IP options in play the pointer is NULL and there is nothing to free — which is why the bug is invisible on most networks.

The main race. When the handshake completes, tcp_v4_syn_recv_sock() creates the child socket and hands it the options buffer by pointer (newinet->inet_opt), without copying. At the same time another CPU can be processing a retransmitted SYN for the same request socket and start sending a SYN-ACK (tcp_check_req() → tcp_v4_send_synack()), reading that same buffer. That reader holds only rcu_read_lock(). Nothing keeps the child alive: since 079096f103fa (v4.4) request sockets are processed without the listener lock, so the child can be torn down while the SYN-ACK is still being built. inet_sock_destruct() freed the buffer with a plain kfree(), not after an RCU grace period, and ip_options_build() then reads freed memory — twice, for optlen, so it can even see two different lengths.

The migration race. With net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program attached, reqsk_timer_handler() clones the request socket and the clone shares the original’s ireq_opt. When the clone is freed by tcp_v4_reqsk_destructor() — again a plain kfree() — a CPU still working on the original (sending a SYN-ACK, or creating the child) reads freed memory. This variant exists since c905dee62232 (v5.14) and is off by default.

What goes wrong. Once the freed ip_options_rcu object is reused, ip_options_build() copies optlen bytes of whatever now sits there into the outgoing SYN-ACK (heap bytes leak to the peer), and uses the stale srr / rr / ts offsets to write addresses and timestamps into the packet (out-of-bounds kernel writes). A stale optlen can also push skb_push() past the SYN-ACK’s headroom and panic the kernel outright. A crash is the likely result; turning the writes into code execution is theoretical and nobody has published an attempt.

The fix, e3f33b0a1d89, frees both buffers with kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(), so an RCU reader that already holds the pointer finishes before the memory is reused — the same discipline the other paths that replace a socket’s options (do_ip_setsockopt(), cipso_v4_sock_setattr()) already used. IPv6 is not affected by the main race, because tcp_v6_syn_recv_sock() copies the options instead of sharing them.

⚠️ Because the introducing commit landed in v4.4 (January 2016), this is not a recent-regression bug: there is no in-support kernel old enough to be unaffected. A kernel is safe only by carrying the e3f33b0a1d89 fix — not by being old.

Vulnerable commit range

The reachable lifetime runs from v4.4 through v7.1 (and 7.2 before 7.2.10). No in-support kernel predates the flaw, so the only not-affected kernels are those that carry the fix.

Patch status

A row is Fixed only if its kernel carries the e3f33b0a1d89 backport; every kernel from 4.4 on without it is in-window and Vulnerable. The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. Current kernel is the package or point release current at the last update; First fixed and Fixed since record the first build carrying the fix and the date it shipped.

Linux kernel

The fix reached mainline in v7.3-rc7 through the netdev tree, and has been backported to every maintained stable and long-term line. 7.2 and 6.18 picked it up in their 2026-10-11 point releases; 6.12, 6.6, 6.1, 5.15 and 5.10 four days later, on the day the CVE was published. v7.3 itself has since entered normal stable maintenance with its own point releases, carrying the fix from its first release onward.

7.1.x never received it. The 7.1 line reached end of life at 7.1.13, a month before the fix existed, so every 7.1 release stays vulnerable — move to 7.3 or a long-term line.

7.2.x is now closed, but fixed. The line reached end of life at 7.2.15 on 2026-11-01, already carrying the fix since 7.2.10 — a host still on it is safe from this CVE but gets no further updates of any kind, so move to 7.3 or a long-term line regardless.

To check a tree directly: a fixed inet_sock_destruct() (in net/ipv4/af_inet.c) releases inet->inet_opt with kfree_rcu(), and so does tcp_v4_reqsk_destructor() (in net/ipv4/tcp_ipv4.c) for ireq_opt; an unfixed tree calls kfree() in both places.

Debian

forky is testing, the future Debian 14. bookworm’s opt-in 6.12 kernel is the linux-6.12 package in bookworm-security: trixie’s kernel rebuilt for bookworm.

Every suite tracked here carries the fix through its security archive: trixie as a DSA in trixie-security, bookworm’s default linux as a Debian LTS upload (oldstable’s security support has passed from the security team to the LTS team), and linux-6.12 as its own DLA. When tracking ended, the plain trixie and bookworm suites still held older kernels, pending the next point release; the fixed trixie kernel was accepted into proposed-updates on 2026-10-29 for exactly that. A host that applies security updates is fixed; one that pins the base suite is not.

The trixie-backports kernel (linux 7.2.11-1~bpo13+1, uploaded 2026-10-24) is built from a fixed upstream release too.

bullseye (Debian 11) left LTS support on 2026-08-31, before this bug was disclosed. Its 5.10-line default kernel and the former linux-6.1 opt-in stay vulnerable, and no fix is coming — upgrade to bookworm or newer.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over. PVE 9’s default proxmox-kernel-7.0 carries the fix from 7.0.14-25 on, not as a named cherry-pick but by rebasing onto Ubuntu’s 7.0.0-43.43 kernel source, whose tree already holds both kfree_rcu() changes. When tracking ended, Ubuntu’s own tracker still listed that version as pending, because Ubuntu’s archive had not published it — the Proxmox build was ahead of the Ubuntu one it was cut from.

• PVE 8 reached end of life in August 2026, before any fix existed. Its default proxmox-kernel-6.8 and the bookworm-backports opt-in proxmox-kernel-6.14 stay vulnerable, and no fix is coming — upgrade to PVE 9.
• Abandoned preview series that PVE 9 still publishes, proxmox-kernel-6.17 (last updated 2026-07-28) and proxmox-kernel-6.14 (2026-05-15), will never get the fix. A host booting one should switch to the default kernel.

On a Proxmox host the exposed kernel is the host’s: every LXC container shares it, so a TCP service listening inside a container exposes the host kernel exactly as a service on the host itself does. VMs run their own kernel and are covered by their own distribution’s row.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix. nixpkgs also pins the older long-term series (linux_6_12, linux_6_6, linux_6_1) at fixed releases, so a host overriding the default is fixed too, as long as it tracks a ref current enough to have picked up the mid-October bumps.

master dropped linux_5_10 and linux_5_15 outright on 2026-10-06, ahead of their upcoming upstream end of life; release-26.05 still defines both, pinned at their own fixed releases.

Kernel updates land on nixpkgs master first and reach each channel once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) run a reduced jobset and pick up kernel updates fastest.

Which ref a flake input follows:

• github:NixOS/nixpkgs/nixos-unstable and github:NixOS/nixpkgs/nixos-26.05 follow those channels — the GitHub channel branches are updated to exactly the published channel pins.
• A bare github:NixOS/nixpkgs with no ref follows master, and github:NixOS/nixpkgs/release-26.05 follows that branch. Both are ungated development branches — they carry a kernel bump as soon as it lands, often a day or more before a channel publishes it.
• A bare nixpkgs registry input resolves by default to the nixpkgs-unstable channel: a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

All three EL lines — EL10 (6.12-based), EL9 (5.14-based) and EL8 (4.18-based) — postdate the v4.4 introduction, so all are in-window. RHEL 7’s 3.10 kernel predates it and is not affected.

Red Hat shipped RHSAs for the regular kernel package on all three releases on 2026-11-01 — RHSA-2026:93414 (EL8), RHSA-2026:93412 (EL9), RHSA-2026:93413 (EL10) — and its own severity matches the kernel CNA’s vector exactly, 9.8 Critical, up from the Moderate 5.9 it carried at disclosure. Rocky Linux, AlmaLinux and Oracle Linux’s Red Hat Compatible Kernel, all rebuilt from RHEL’s sources, cannot be fixed before RHEL is. Rocky published builds at the exact RHSA kernel NVRs on all three releases the next day.

RHEL 8’s real-time kernel (kernel-rt) picked up its own fix the same day, as RHSA-2026:93415. RHEL 9’s kernel-rt had not when tracking ended — Red Hat listed it Affected with no advisory, unlike the regular kernel it usually ships alongside.

Amazon Linux

All three AL2023 kernel streams — the default kernel (6.1 line), kernel6.12, and kernel6.18 — carry the fix, each via its own ALAS naming the CVE.

Every one of these rows is dated by the fixed build’s arrival in the repository, not by the advisory: Amazon’s feed issued the kernel6.18 advisory a week after its build shipped, and dates both the kernel6.12 and default-stream advisories after this tracker’s seed day even though their builds had already been in the repository for days by then.

Amazon Linux 2 reached end of support on 2026-06-30, before this bug was disclosed. Its kernels, 4.14 on, stay vulnerable, with no fix coming — migrate to AL2023.

Detection

Is the running kernel in the affected window and missing the fix? Every kernel from 4.4 on is in-window; compare the running kernel against the Patch status table’s First fixed column for its series (distro builds below that number can still carry a cherry-pick — the table’s Status is the verdict):

uname -r

Is the host accepting TCP connections? The race needs a listening TCP socket that a peer can reach. Any listener counts — the bug is in the handshake, before the application sees the connection:

ss -ltn

Do IP-options packets reach the host? There is no local switch for this; it depends on what the network in front of the host lets through. Where you control the edge, check the firewall for a rule that drops IPv4 packets carrying header options (see Mitigation); where you don’t, assume they arrive.

Is request-socket migration enabled? The second race needs it, and it is off by default. 1 means a retransmitted SYN-ACK can migrate the request socket to another listener in the same reuseport group:

sysctl net.ipv4.tcp_migrate_req

Public PoC

No exploit code is public, but a working exploit has been described. Anthropic, whose Xinyang Ge is the fix’s Reported-by, wrote on 2026-10-27 in Discovering and exploiting vulnerabilities in critical, real-world software with Claude that its model built a two-stage exploit. The first stage defeats KASLR: the race makes the kernel copy extra bytes into the SYN-ACK until one reply carries a kernel pointer. The second stage overflows a buffer to overwrite a callback pointer with the address of a payload already staged in kernel memory, and the payload ends in an attacker-chosen shell command running as root. Their proof of concept took 48 minutes to leak a pointer and five more to reach the shell, and a lost race only fails that handshake, so the attacker can keep retrying.

The post describes the target as a Linux server “with a multipath TCP listener”. The fix and the CVE record are about plain IPv4 TCP and say nothing about MPTCP, so treat the MPTCP listener as part of this chain’s setup rather than as a precondition for the bug.

The exploit itself is withheld under Anthropic’s disclosure policy, no third-party exploit or crash reproducer has appeared, and the bug is not in CISA’s KEV catalogue. EPSS still scores it low, which reflects the absence of public code and of observed exploitation, not difficulty: the write-up shows the chain is practical.

Mitigation

The real fix is a patched kernel (the e3f33b0a1d89 backport). Until one is installed, the exposure is narrowed by keeping IP-options packets away from the TCP stack — this removes the trigger for both races but is not a fix, and never earns a row its green mark.

Drop IPv4 packets carrying header options

An IPv4 header longer than the minimum 20 bytes (five 32-bit words) carries options. Dropping those packets at the host blocks the SYNs this bug needs, and almost nothing legitimate uses IPv4 options any more; dropping them at the network edge protects every host behind it. The rule assumes an existing inet filter table with an input chain — adapt the table and chain names to the host’s ruleset:

sudo nft add rule inet filter input ip hdrlength > 5 drop

Keep request-socket migration off

net.ipv4.tcp_migrate_req defaults to 0. Leave it there until the host is patched; a host that enables it for reuseport listener rotation also exposes the second race (persist the setting in /etc/sysctl.d/):

sudo sysctl -w net.ipv4.tcp_migrate_req=0

Risk notes

• Remote and unauthenticated, but gated on IP options. Every listening TCP service is a target, with no credentials needed — yet only for peers whose SYNs arrive with IPv4 header options intact. Many networks drop those packets, so the exposure of an Internet-facing host depends on the path in front of it, not just on the kernel.
• Root, not just a crash. The easy result of winning the race is a kernel panic, but Anthropic’s withheld proof of concept chains the heap disclosure and corruption from the stale ip_options_rcu object into remote root command execution within an hour, and a lost race costs the attacker nothing but a failed handshake. Red Hat’s own score now matches the kernel CNA’s 9.8 exactly. No exploit code is public.
• No kernel is too old to be affected. The bug dates from v4.4 (January 2016). Every in-support distribution kernel, including the RHEL 8 4.18 line and the Amazon Linux 6.1 line, is in-window and unsafe until it carries the backport.
• Backports available (CVE-2026-98432): the fix has landed in 7.3-rc7, 7.2.10, 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272. Debian, Proxmox VE 9, NixOS, all three Amazon Linux 2023 kernel streams, RHEL 8, 9, and 10, and now Rocky Linux 8, 9, and 10 all ship it. The 7.1.y line is end-of-life without it.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References