Linux Kernel TCP Use-After-Free CVE-2026-98432: Mitigating Unpatched Ubuntu Hosts, Hunting Exploitation and Patching

The Linux kernel CVE team published CVE-2026-98432 on October 15, 2026, with the fix already in mainline 7.3-rc7 and backported to every maintained stable branch. It drew little attention until October 27, when Anthropic’s Frontier Red Team described a working exploit: remote, zero-click command execution as root against Linux servers with a Multipath TCP (MPTCP) listener. Red Hat rated it Critical on October 30 and shipped fixed RHEL kernels on November 1 and 2. AWS, Debian and SUSE have fixes out.

Ubuntu is the gap. As of November 3, Canonical has published no Ubuntu Security Notice and no Livepatch notice for this CVE. Its tracker marks the fix as pending for Ubuntu 22.04, 24.04, 26.04 and 26.10, and Launchpad shows the fixed kernels have been in the -proposed pocket since October 26 to 28. Ubuntu 20.04 and older ESM releases, and the 24.04 HWE 6.17 and 7.0 kernels, show needed with no fix staged. If your DevOps team says “Ubuntu hasn’t released it yet”, they are right, and the interim mitigation below is what to do until it lands.

There is no public report of exploitation in the wild. AWS states it has no evidence of exploitation, and the CVE is absent from CISA’s Known Exploited Vulnerabilities catalog. We found no public exploit code. Anthropic described the exploit chain but did not publish it.

This advisory covers how the bug works, which hosts to fix first, the patch status for each distribution, the network mitigation Red Hat and AWS publish, and how to hunt for attempts and for signs of a successful exploit.

How the flaw works

When a Linux server accepts an IPv4 TCP connection, the IP options from the client’s SYN are saved on the half-open request socket (ireq_opt). When the handshake completes, tcp_v4_syn_recv_sock() hands those options to the new child socket without copying them.

Since kernel 4.4, request sockets are processed without holding the listener lock. That means another CPU can be handling a retransmitted SYN for the same request at the same moment, building a SYN-ACK in tcp_v4_send_synack() that reads the options. If the child socket is freed in between, inet_sock_destruct() frees the options with a plain kfree(), and ip_options_build() reads freed memory. The fix frees the options only after an RCU grace period (kfree_rcu()).

A second path exists with request socket migration, when net.ipv4.tcp_migrate_req=1 or a BPF SK_REUSEPORT migrate program is in use. The default for that setting is 0.

The kernel CNA’s own scoring notes in the CVE record spell out what an attacker gets:

• Information leak. The stale option length makes the kernel copy extra heap bytes into the SYN-ACK it sends back to the attacker.
• Memory corruption. Reclaimed option offsets steer writes in ip_options_build(), which allows out-of-bounds kernel writes.
• Crash. An oversized length can trigger skb_under_panic() and take the host down.

What the exploit achieved

Anthropic’s write-up describes a two-stage remote exploit against a host with an MPTCP listener:

1. Defeat KASLR remotely. The over-read leaks a kernel pointer in a SYN-ACK, which reveals the kernel’s memory layout.
2. Take control. The same use-after-free overflows a buffer and overwrites a callback pointer. That pointer leads to a payload staged in kernel memory, which chains existing kernel functions and finishes by running a shell command as root.

A lost race only fails that handshake, so the attacker can retry indefinitely without crashing the host. In Anthropic’s proof of concept, the pointer leak took 48 minutes and code execution another 5 minutes. Expect a long, noisy stream of handshakes from one source, not a single packet.

MPTCP is not a precondition

The bug is in the plain IPv4 TCP path. Red Hat states that MPTCP is not required and that hosts with MPTCP disabled are still affected. The MPTCP listener is the setup Anthropic chose for its exploit, not a precondition for the bug.

MPTCP listeners are also more common than many teams assume. Go 1.24 and later use MPTCP by default for listeners on Linux, so many modern Go services listen on MPTCP sockets without anyone choosing it.

Who is exposed, in priority order

The attacker’s SYN, with its IP options, has to reach the vulnerable kernel directly. Rank your fleet this way:

1. Internet-facing Linux hosts that accept TCP themselves. This includes SSH bastions, VPN and reverse proxy hosts, load balancer appliances, mail and web servers, and Kubernetes nodes exposed through NodePort, hostNetwork or TCP passthrough load balancers.
2. Hosts running Go 1.24+ services or other MPTCP listeners. This matches the exploit Anthropic demonstrated. ss -Mltn lists MPTCP listeners.
3. Hosts behind layer 4 passthrough. AWS notes that Network Load Balancer TCP listeners, Global Accelerator, PrivateLink and VPC Lattice pass IP options through to targets.
4. Internal Linux servers. These are reachable by anyone already inside the network.

Lower priority are hosts that sit only behind a proxy or an application load balancer that terminates TCP and opens its own connection to the backend. AWS has patched its own infrastructure for ALB, Classic Load Balancer, CloudFront and API Gateway, and asks customers to patch the instances behind them within 30 days. The proxy host itself, if it runs Linux, is in group 1.

Containers share the host kernel. A vulnerable node means every container on it is exposed, and patching happens at the node.

Patch status by distribution

Upstream stable kernels with the fix: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and mainline 7.3. The flaw was introduced in 4.4. The fix commit is titled “ipv4: free inet_opt and ireq_opt after an RCU grace period”. That title appears in distribution changelogs, which makes it the easiest way to confirm a kernel is fixed.

Ubuntu (not released as of November 3)

Pending means Canonical has built the fix and not yet released it to the security and updates pockets. Ubuntu Livepatch has not covered this CVE: the latest Livepatch notice, LSN-0122-1, dates from October 7. On Ubuntu Pro machines, pro fix CVE-2026-98432 will apply the fix once it is released.

The -proposed pocket is Canonical’s pre-release testing channel. Installing the kernel from it is an option for a test fleet, or for a high-risk internet-facing host where you accept the risk of an unreleased kernel. Install only the kernel packages from it, never the whole pocket. For everything else, apply the mitigation below and patch when the USN ships.

Red Hat Enterprise Linux

Red Hat’s machine-readable status data still lists OpenShift Container Platform 4 and 5 (RHEL CoreOS) as affected with no fix, along with some RHEL 9 kernel-rt builds. For other extended update streams, check Red Hat’s CVE page. Red Hat’s bulletin is still marked “Ongoing” and does not yet list these errata.

Debian

SUSE

• Released: SLES 15 SP4, SP5 and SP6 LTSS, SLES 16.0, SLE Micro 5.3 to 5.5, SL Micro 6.2 and openSUSE Leap 16.0.
• Still in progress: SLES 15 SP7 and SLES 12 SP5 LTSS.
• Affected, no fix yet: openSUSE Leap 15.x and SL Micro 6.0 and 6.1.
• SUSE rates the CVE 8.1 (Important) because it scores attack complexity as high.

Amazon Web Services

• Amazon Linux 2: fixed kernels for 4.14, 5.4, 5.10 and 5.15.
• Amazon Linux 2023: fixed kernels for 6.1, 6.12 and 6.18. Instances locked to a release need 2023.12.20261102 or later.
• EKS and ECS: AMI releases dated October 31.
• Fargate: tasks and pods launched after November 1, 9:00 AM PST run patched.
• Bottlerocket: patched kernel released; updated AMIs from November 2.
• Ubuntu on AWS: waits on Canonical.

How to check a host

# Running kernel, and whether the fix is in its changelog
uname -r
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -m1 "ireq_opt after an RCU grace period"   # Debian, Ubuntu
rpm -q --changelog kernel | grep -m1 -i "CVE-2026-98432"                                            # RHEL family

# Exposure: IPv4 TCP listeners, MPTCP listeners, and the related settings
ss -ltn4
ss -Mltnp
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

# Ubuntu Pro hosts
pro fix CVE-2026-98432 --dry-run

A fixed package that is installed but not booted still leaves the host vulnerable. Compare uname -r with the newest installed kernel, and reboot.

Mitigating until you can patch

None of these steps fixes the bug. They narrow the path to it until the patched kernel is installed and running.

1. Drop IPv4 TCP packets that carry IP options

The attack needs IPv4 options in the TCP SYN. Normal TCP traffic almost never carries them. Red Hat publishes this nftables table, which drops incoming IPv4 TCP packets whose header is longer than the standard 20 bytes:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432      # the counter shows packets dropped
sudo nft delete table inet cve_2026_98432    # after the patched kernel is running

AWS gives an iptables version. It matches an IP header length of 6 to 15 words, so it drops every incoming IPv4 packet with options, not only TCP:

sudo iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Points to know before rolling it out:

• The rule is lost on reboot unless you persist it. Add the nft file to /etc/nftables.conf or load it from a boot-time unit. It runs alongside ufw, firewalld or iptables-nft rules as its own table.
• Kubernetes nodes need more than the input chain. An input-hook rule only filters traffic addressed to the node’s own network namespace. Red Hat notes that pod-to-pod traffic inside the cluster network is not filtered. For traffic routed to pods, add the same match in a forward-hook chain on each node, then test it.
• Filter at the edge too. AWS describes a Network Firewall stateful rule that drops IPv4 packets with a header length above 5, in strict rule order. Most firewalls can drop packets with IP options; dropping them at the perimeter protects hosts you have not reached yet.
• Test first. Red Hat warns the rule may disrupt workloads that rely on IP options. Watch the counter for a day on a canary host before rolling it out.

2. Close the published exploit path

The mitigation that counts is rule 1. These steps narrow the route Anthropic used, but they do not fix the bug:

• Disable MPTCP where you do not need it: sysctl -w net.mptcp.enabled=0. The setting is per network namespace, so setting it on the host does not cover containers.
• For Go 1.24+ services, set GODEBUG=multipathtcp=0 in the service environment.

3. Keep request socket migration off

Leave net.ipv4.tcp_migrate_req at its default of 0, and inventory any BPF SK_REUSEPORT migrate programs. This removes the second race path.

4. Reduce what is reachable

Close inbound TCP ports that do not need to be open. Where you can, put services behind a proxy that terminates TCP, so attacker packets never reach the backend kernel.

5. Plan the reboot now

Kernel fixes need a reboot, and no Livepatch notice covers this CVE yet. Line up maintenance windows for internet-facing Ubuntu hosts so you can reboot within a day of the USN.

Threat hunting

Hunt from October 15, 2026, the day the CVE and the fix became public. For internet-facing hosts, go back as far as your telemetry allows.

Set expectations first. An attempt is a long run of TCP handshakes from one source whose SYNs carry IPv4 Record Route or Timestamp options. Most firewalls and flow logs do not record IP options, so packet-level sensors and the nftables counter are your best attempt signals. A successful exploit ends with a root command started from kernel context. A failed one can crash the host.

The KQL below is example code for Microsoft Defender for Endpoint and Microsoft Sentinel. Adapt the table and field names to your environment and test each query before relying on it.

Hunt 1: vulnerable and exposed Linux devices

If Defender Vulnerability Management has mapped the CVE, start with its list. Then add internet exposure and listening ports.

// Example: devices Defender maps to CVE-2026-98432
DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2026-98432"
| summarize Packages=make_set(SoftwareName, 10), Versions=make_set(SoftwareVersion, 10) by DeviceId, DeviceName, OSPlatform

// Example: Linux devices, internet exposure and accepted inbound ports in the last 7 days
DeviceInfo
| where Timestamp > ago(7d) and OSPlatform == "Linux"
| summarize arg_max(Timestamp, OSDistribution, OSVersionInfo, PublicIP, IsInternetFacing) by DeviceId, DeviceName
| join kind=leftouter (
    DeviceNetworkEvents
    | where Timestamp > ago(7d) and ActionType == "InboundConnectionAccepted"
    | summarize InboundPorts=make_set(LocalPort, 50), RemoteSources=dcount(RemoteIP) by DeviceId
  ) on DeviceId
| project DeviceName, OSDistribution, OSVersionInfo, IsInternetFacing, PublicIP, InboundPorts, RemoteSources
| order by IsInternetFacing desc, RemoteSources desc

Hunt 2: SYNs carrying IP options on the wire

If you run Suricata on a span port or a cloud traffic mirror, these rules flag the trigger packet arriving, and the tell-tale reply leaving. A vulnerable server copies the client’s options into its SYN-ACK, so an outbound SYN-ACK with IP options from your own hosts means a vulnerable handshake took place. The sids are local examples; renumber them for your ruleset.

alert tcp any any -> $HOME_NET any (msg:"CVE-2026-98432 inbound TCP SYN with IPv4 Record Route option"; flags:S,12; ipopts:rr; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-admin; sid:9843201; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"CVE-2026-98432 inbound TCP SYN with IPv4 Timestamp option"; flags:S,12; ipopts:ts; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-admin; sid:9843202; rev:1;)
alert tcp $HOME_NET any -> any any (msg:"CVE-2026-98432 outbound SYN-ACK carrying IPv4 options"; flags:SA,12; ipopts:any; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-admin; sid:9843203; rev:1;)

Without a sensor, capture on a suspect host for a while:

sudo tcpdump -ni any 'ip[0] & 0x0f > 5 and tcp[tcpflags] & tcp-syn != 0'

Once the nftables mitigation is in place, its counter is a detection in itself. Ship nft list table inet cve_2026_98432 output to your monitoring and alert when the count rises.

Hunt 3: kernel crashes in the TCP handshake path

Failed races can oops or panic the kernel. Look for crash text that names the functions in this bug.

// Example: Sentinel Syslog, kernel messages naming the vulnerable path
Syslog
| where TimeGenerated > datetime(2026-10-15)
| where Facility == "kern"
| where SyslogMessage has_any ("skb_under_panic", "ip_options_build", "ip_build_and_send_pkt",
                               "tcp_v4_send_synack", "tcp_rtx_synack", "inet_sock_destruct", "tcp_v4_reqsk_destructor")
| project TimeGenerated, Computer, HostIP, SyslogMessage
| order by TimeGenerated desc

A panic often stops the agent before it ships the log. Look for unexplained gaps instead, then check journalctl -k -b -1, pstore or kdump output on the host itself.

// Example: Linux agents that went silent for more than 10 minutes (possible crash and reboot)
Heartbeat
| where TimeGenerated > datetime(2026-10-15) and OSType == "Linux"
| sort by Computer asc, TimeGenerated asc
| extend Gap = TimeGenerated - prev(TimeGenerated), SameHost = Computer == prev(Computer)
| where SameHost and Gap > 10m
| project Computer, SilentFrom = TimeGenerated - Gap, BackAt = TimeGenerated, Gap
| order by BackAt desc

Hunt 4: a root command started from kernel context

Anthropic’s exploit ends by running a shell command as root from inside the kernel. Anthropic does not name the kernel function used. Our working assumption is that the command is started the way the kernel normally starts user programs, which makes the process a child of a kernel thread rather than of sshd, systemd or a service. This query looks for interpreters and download tools with a kernel-thread parent. Baseline it first, because helpers such as modprobe and crash handlers legitimately start this way.

// Example: shells and download tools whose parent is a kernel thread
DeviceProcessEvents
| where Timestamp > datetime(2026-10-15)
| where InitiatingProcessFileName =~ "kthreadd" or InitiatingProcessFileName startswith "kworker"
| where FileName in~ ("sh", "bash", "dash", "busybox", "python3", "perl", "curl", "wget", "nc", "ncat", "socat")
| where not(ProcessCommandLine has_any ("modprobe", "systemd-coredump", "apport"))
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

Hunt 5: what an attacker does next as root

After the first command runs, the activity looks like any other Linux intrusion. Watch internet-facing hosts for root shells calling out, and for new persistence.

// Example: root-owned shells and network tools connecting to public addresses
DeviceNetworkEvents
| where Timestamp > datetime(2026-10-15)
| where InitiatingProcessAccountName == "root"
| where InitiatingProcessFileName in~ ("sh", "bash", "dash", "nc", "ncat", "socat", "curl", "wget", "python3", "perl")
| where RemoteIPType == "Public"
| summarize Connections=count(), First=min(Timestamp), Last=max(Timestamp), Commands=make_set(InitiatingProcessCommandLine, 10)
    by DeviceName, RemoteIP, RemotePort
| order by First desc

// Example: new SSH keys, cron jobs, systemd units and preload entries written by shells or tools
DeviceFileEvents
| where Timestamp > datetime(2026-10-15)
| where FolderPath has_any ("/root/.ssh/", "/etc/cron", "/var/spool/cron", "/etc/systemd/system", "/etc/ld.so.preload")
| where InitiatingProcessFileName in~ ("sh", "bash", "dash", "curl", "wget", "python3", "perl", "echo", "cp", "mv")
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Responding to evidence of an attempt

1. Find the source and block it at the edge. Then confirm the nftables or iptables drop rule is active on the target.
2. Preserve evidence before rebooting:
3. the nft counter, packet captures and journalctl -k
4. any crash dumps
5. a process list (ps -eo pid,ppid,user,lstart,cmd)
6. network connections (ss -tanp)
7. Check for code execution. Run Hunts 4 and 5 against the host, and review /root/.ssh, cron, systemd units, loaded kernel modules (lsmod) and /etc/ld.so.preload.
8. Rebuild if you find evidence of execution. Root obtained through the kernel means the host cannot be trusted. Rebuild it from known-good media on a fixed kernel, and rotate every secret it held: SSH host and user keys, cloud credentials, service tokens and database passwords.
9. If there is no sign of execution, patch, reboot and keep the network rule until the fixed kernel is running everywhere behind the same exposure.

Detection rules to keep

• Inbound TCP SYN carrying IPv4 Record Route or Timestamp options, from any source.
• Outbound SYN-ACK with IP options from your own hosts.
• nftables cve_2026_98432 counter increasing.
• Kernel oops or panic text naming ip_options_build, skb_under_panic or tcp_v4_send_synack.
• Linux host offline for more than 10 minutes without a change ticket.
• Shell, interpreter or download tool whose parent is kthreadd or a kworker thread.
• Internet-facing Linux host still running a kernel older than the fixed version, 24 hours after the vendor fix ships.

Timeline

• September 25, 2026: the Linux kernel CNA reserves CVE-2026-98432.
• October 15: the CVE is published, with the fix in mainline 7.3-rc7 and backports in the stable branches.
• October 26: fixed Ubuntu 22.04 and 24.04 kernels enter -proposed.
• October 27: Anthropic’s Frontier Red Team describes a remote root exploit against hosts with an MPTCP listener.
• October 28: the fixed Ubuntu 26.04 kernel enters -proposed.
• October 29: SUSE releases its first fixed kernels.
• October 30: Red Hat publishes bulletin RHSB-2026-016, rated Critical, with the nftables mitigation. AWS publishes bulletin 2026-160-AWS.
• October 31: EKS and ECS ship patched AMIs.
• November 1: Red Hat ships fixed kernels for RHEL 8.10, 9.8 and 10.2.
• November 2: Red Hat ships fixed kernels for RHEL 9.4 E4S and RHEL 10 for NVIDIA.
• November 3: still no Ubuntu Security Notice or Livepatch notice. The CVE is not in CISA KEV.

Frequently Asked Questions

Has Ubuntu released a fix for CVE-2026-98432? Not as of November 3, 2026. Fixed kernels for 22.04, 24.04 and 26.04 have been in the -proposed pocket since October 26 to 28. Ubuntu 26.10 is pending. 20.04 and older ESM releases, and the 24.04 HWE 6.17 and 7.0 kernels, have no fix staged.

Do we need MPTCP enabled to be vulnerable? No. The bug is in the ordinary IPv4 TCP handshake. MPTCP was the setup used in Anthropic’s exploit, and Red Hat states that hosts with MPTCP disabled are still affected.

Is there a public exploit? We found none. Anthropic described the exploit chain in detail but did not publish code. Expect that to change: the fix commit and the CVE record explain the race precisely.

Is it being exploited? There is no public report of exploitation in the wild as of November 3, 2026. AWS states it has no evidence of exploitation, and the CVE is not in the CISA KEV catalog.

Will dropping packets with IP options break anything? Normal TCP traffic does not use IPv4 options, and the rule matches TCP only. Red Hat still advises testing first, because some specialized workloads may rely on them.

Is IPv6 affected? The main race is IPv4 only. The CVE notes a related IPv6 migration issue that only applies with CALIPSO, which will be fixed separately.

Are containers protected by their own settings? No. Containers share the host kernel, so the node must be patched. MPTCP and some network settings are per network namespace, so host-level sysctl changes do not reach containers.

Why is the score 9.8 at some vendors and 8.1 at others? The kernel CNA and Red Hat score attack complexity as low, because the attacker controls both sides of the race and can retry. SUSE scores it high because the race has to be won. Both agree it is remote and unauthenticated.

How ThreatDefence is responding

ThreatDefence is tracking CVE-2026-98432 in our vulnerability intelligence. Where we hold endpoint and network telemetry, our SOC is:

• identifying internet-facing Linux hosts on unfixed kernels
• watching for TCP SYNs carrying IP options and for kernel crash patterns
• reviewing Linux hosts for root activity started from kernel context

If you run Ubuntu fleets waiting on Canonical’s fix and want help rolling out the interim mitigation or running a retrospective hunt, contact us.

Sources

• Linux kernel CNA, CVE-2026-98432 record (October 15, 2026, updated October 31, 2026)
• Linux kernel, fix commit e3f33b0a1d89: ipv4: free inet_opt and ireq_opt after an RCU grace period
• Anthropic Frontier Red Team, Discovering vulnerabilities with Claude (October 27, 2026)
• Red Hat, RHSB-2026-016 Use-after-free in kernel IPv4 (October 30, 2026, updated November 2, 2026)
• Red Hat, CVE-2026-98432 (accessed November 3, 2026)
• Red Hat, RHSA-2026:93412 (November 1, 2026)
• Red Hat, RHSA-2026:93413 (November 1, 2026)
• Red Hat, RHSA-2026:93414 (November 1, 2026)
• Red Hat, RHSA-2026:93415 (November 1, 2026)
• Red Hat, RHSA-2026:93775 (November 2, 2026)
• Red Hat, RHSA-2026:94109 (November 2, 2026)
• Canonical, Ubuntu CVE tracker: CVE-2026-98432 (checked November 3, 2026)
• Canonical, Launchpad: linux 6.8.0-149.149 changelog (accessed November 3, 2026)
• Debian, security tracker: CVE-2026-98432 (checked November 3, 2026)
• SUSE, CVE-2026-98432 (checked November 3, 2026)
• AWS, Security bulletin 2026-160-AWS: CVE-2026-98432 (October 30, 2026, updated November 2, 2026)
• Go, Go 1.24 release notes: net package (accessed November 3, 2026)
• CISA, Known Exploited Vulnerabilities catalog (checked November 3, 2026)