Blog · Security · Published 3 November 2026

Linux Kernel TCP Use-After-Free (CVE-2026-98432): How to Check, Mitigate, and Patch

A race in the Linux kernel's IPv4 TCP connection handling lets a remote, unauthenticated attacker free socket memory that is still in use. At worst that is kernel memory corruption; at best, a crash. Here is how to tell what kernel you are really running, what to do before the patch lands, and how to prove you are no longer exposed.

TL;DR

• Patch the kernel and reboot (or apply a vendor livepatch). Installing a new kernel package changes nothing until the new kernel is actually running.
• Can't patch yet? Red Hat's interim mitigation drops inbound IPv4 TCP packets that carry IP options — rarely used by legitimate traffic. It reduces exposure; it does not close the bug.
• MPTCP is not required. The flaw is in ordinary IPv4 TCP; disabling Multipath TCP does not make a host safe.
• Severity is rated Critical; scores range from CVSS 9.8 (kernel CNA, Ubuntu) to 8.1 (Red Hat, Oracle, SUSE) to 7.0 (Amazon).
• As of 3 November 2026: Debian, Oracle UEK and most SUSE releases ship a fix; Red Hat and Ubuntu are still in progress. Check your tracker.

What the vulnerability is

Red Hat describes CVE-2026-98432 as a use-after-free that “arises when socket options are freed while still being accessed by a concurrent operation, such as a retransmitted connection request or a socket migration.” In plain terms: during the TCP handshake the kernel can release the memory holding a connection's IPv4 options while another CPU is still reading it. Win that race and you read or corrupt freed kernel memory.

The reporter — a researcher who disclosed the bug through Anthropic — has stated they built a working exploit achieving remote root against servers running a Multipath TCP listener. At least one vendor kernel team (CloudLinux) reported it could not reproduce that remote-root result. Treat the two claims as what they are: the underlying flaw is confirmed and critical, while the reliability of full remote code execution against an arbitrary service is contested. Either way, the remediation is identical — patch the kernel.

Step 1 — Find out what kernel is actually running

Inventory the running version first, and whether a newer kernel is already staged and waiting on a reboot. These are different questions, and the gap between them is where this CVE hides.

# What is running right now — this is the only version that matters for exposure
uname -r

# Debian / Ubuntu: is a newer kernel installed but not yet booted?
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'
[ -f /run/reboot-required ] && cat /run/reboot-required   # reboot pending?

# RHEL / derivatives: installed kernels, and whether a reboot is needed
rpm -q kernel
needs-restarting -r 2>/dev/null   # from dnf-utils / yum-utils

# Across a fleet via SSH — collect running kernels in one pass
for h in $(cat hosts.txt); do
  printf '%s: ' "$h"; ssh -o ConnectTimeout=5 "$h" uname -r 2>/dev/null || echo unreachable
done

# Containers share the host kernel — only the node's uname -r matters, not the image

Step 2 — If you can't patch today: the interim mitigation

Reaching the bug requires IPv4 packets that carry IP options. Legitimate traffic almost never does, so Red Hat's interim mitigation drops inbound IPv4 TCP packets whose IP header is longer than the standard 20 bytes (i.e. it carries options). Save this as cve-2026-98432.nft:

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

Validate, apply, and confirm it is loaded:

sudo nft --check --file cve-2026-98432.nft   # parse without applying
sudo nft --file cve-2026-98432.nft           # apply
sudo nft list table inet cve_2026_98432      # confirm, and watch the drop counter

Step 3 — Patch, then reboot (the part that actually fixes it)

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade -y
sudo reboot                      # the new kernel runs only after this

# Ubuntu Pro: apply the fix (and use Livepatch for reboot-free coverage if offered)
sudo pro fix CVE-2026-98432

# RHEL / derivatives
sudo dnf upgrade kernel -y
sudo reboot

# Kubernetes / cloud nodes: patch the node image and cordon-drain-replace,
# or roll the node pool. Restarting pods does NOT change the host kernel.

If rebooting a fleet is the hard part, this is where kernel livepatching earns its keep — Canonical Livepatch, Red Hat kpatch, Oracle Ksplice and SUSE Live Patching can close the gap without an immediate reboot when the vendor ships a livepatch for this CVE. Confirm one exists before assuming you are covered; a livepatch is not guaranteed for every kernel CVE.

Patch status by distribution (snapshot — verify today)

These statuses move fast. Do not take this table as current at the time you read it — open your distribution's advisory and confirm the fixed package version before you decide you are done.

Step 4 — Verify

1. Re-check the running kernel. After the reboot, uname -r must report the fixed version named by your distribution's advisory — on every host, not just the ones that rebooted cleanly.
2. Confirm no reboot is still pending. [ -f /run/reboot-required ] should be false on Debian/Ubuntu; needs-restarting -r should report no reboot needed on RHEL.
3. Remove the interim mitigation once patched so it doesn't linger as hidden state: sudo nft delete table inet cve_2026_98432.
4. Gate it. Add a running-kernel check to your node bootstrap or monitoring so a host on an unpatched kernel is flagged, not silently trusted.

The short version

Patch the kernel and reboot — or livepatch — then prove it with uname -r against the fixed version your vendor names. If a fix isn't out for your distribution yet, drop IPv4-option TCP packets with Red Hat's nftables rule to buy time, and don't be fooled into thinking MPTCP being off makes you safe. The work that makes this a routine reboot cycle rather than a scramble is the same work every kernel CVE rewards: knowing what every node runs, and being able to roll the whole fleet on a new kernel on demand.

If “how fast can we reboot every production node onto a patched kernel, and prove it?” doesn't have a confident answer, that's the thing to fix before the next one lands — more on building that muscle in Is Your Organisation Ready for the Next Critical CVE?

Official sources

• Red Hat RHSB-2026-016 — CVE-2026-98432 (root cause, interim nftables mitigation, patch status)
• Canonical CVE tracker — CVE-2026-98432 (Ubuntu per-release status and fixed versions)
• CVE record — CVE-2026-98432