CVE-2026-98432 kernel TCP flaw: what to do

What CVE-2026-98432 is, and what to do about it

CVE-2026-98432 is a use-after-free bug in the Linux kernel's IPv4 TCP code. The fix is a patched kernel and then a reboot. A use-after-free means the kernel reads memory that it has already released. Linux 4.4 and every later kernel are affected. Kernels older than 4.4 are not.

The kernel CNA (CVE numbering authority) gives it a CVSS 3.1 score of 9.8, Critical, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. That vector means an attacker can reach the bug over the network, with no account and no action from a user. Ubuntu rates it Critical priority. Red Hat also rates it Critical, at 9.8.

Canonical's position is short: "The Ubuntu Security Team believes that security updates are the only appropriate mitigation." Red Hat calls kernel updates "the only complete solution". The firewall rule and the sysctl settings later in this guide lower the risk. None of them closes the bug.

Fix status, as of 7 November 2026

This list is the part of the guide that will go out of date. Each entry was read from the vendor's tracker or advisory on 7 November 2026. Check your own distribution again before you act.

• Ubuntu 26.10: fixed in linux 7.3.0-10.10.
• Ubuntu 26.04 LTS, 24.04 LTS, 22.04 LTS: the tracker shows "Vulnerable, work in progress" at 7.0.0-43.43, 6.8.0-149.149 and 5.15.0-203.213. Canonical's post of 2 November says these same versions are available in the -proposed pocket.
• Ubuntu 20.04, 18.04, 16.04: "work in progress" on the tracker, and "fix pending" in Canonical's post. Ubuntu 14.04 is not affected.
• Debian 12 (bookworm): fixed in bookworm-security, linux 6.1.190-1. The backported linux-6.12 package is fixed at 6.12.113-1~deb12u1.
• Debian 13 (trixie): fixed in trixie-security, which now carries linux 6.12.115-2.
• AlmaLinux 8, 9, 10: patched kernels went to the testing repository on 30 October. Since AlmaLinux's update of 2 November, the fix is in the regular kernel updates in the production repositories: kernel-4.18.0-553.182.1.el8_10, kernel-5.14.0-687.64.1.el9_8 and kernel-6.12.0-211.72.1.el10_2, or higher.
• Rocky Linux 8, 9, 10: advisories RLSA-2026:93414, RLSA-2026:93412 and RLSA-2026:93413 were published on 3 November. They carry the same kernel versions as AlmaLinux and list this CVE.
• Red Hat Enterprise Linux 8, 9, 10: bulletin RHSB-2026-016 is marked "Ongoing" and lists no fixed kernels yet.
• Fedora: no fixed kernel could be confirmed. Look in Bodhi, Fedora's update system, for a kernel update that names the CVE.

On Debian, the plain bookworm and trixie release versions are listed as vulnerable. That is expected. Debian ships kernel fixes through its security suite, so a server that pulls from bookworm-security or trixie-security gets the fixed build.

What the bug actually is

The CVE record's title is "ipv4: free inet_opt and ireq_opt after an RCU grace period". inet_opt and ireq_opt hold the IPv4 options of a socket and of a connection request. RCU (read-copy-update) is a kernel mechanism that lets readers use a structure without taking locks. The rule is that the writer must wait one "grace period" before it frees the structure. These two structures were freed without that wait. As a result, a SYN-ACK sent at the same moment could read memory that had already been freed. The upstream fix frees them with kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor().

IPv6 is not affected by the first issue the CVE record describes, because tcp_v6_syn_recv_sock() duplicates the options. The record says IPv6 does have the same request-socket migration issue, with options that only CALIPSO sets, and that upstream will fix it in a separate patch.

The timeline shows how urgent this is. The fix was committed upstream on 5 October. The CVE was published on 15 October. On 27 October, Anthropic reported that Claude, its AI model, had written a working root exploit against Linux servers that have an MPTCP (Multipath TCP) listener. That exploit has not been published. The exploit was described as using MPTCP, but Canonical says the vulnerability is not specific to MPTCP.

Is the kernel on your VPS fixed?

You need to check two things. First, is a fixed package installed? Second, is the server actually running it? A kernel package on disk protects nothing until you boot into it.

Ubuntu

uname -r
dpkg -l 'linux-image*' | grep ^ii

These are the two checks from Canonical's own post. uname -r prints the running kernel, for example 6.8.0-149-generic. dpkg -l lists the installed kernel packages with their full versions, such as 6.8.0-149.149. You are fixed when two things are true: an installed package is at or above the version for your release in the list above, and uname -r shows that same kernel.

The suffix on uname -r matters. A VPS often runs a cloud flavour kernel, ending in -aws, -gcp or -azure instead of -generic. Those flavours have their own rows on the Ubuntu CVE page, such as linux-aws, with their own version numbers. Compare against the row for your flavour, not the linux row.

Debian

uname -v
dpkg -l 'linux-image*' | grep ^ii

On Debian, uname -r shows only the ABI name, which ends in -amd64 on an x86 server. uname -v includes the package version of the running kernel, for example Debian 6.12.115-2. Compare that number with the security-suite version above.

Rocky Linux and AlmaLinux

uname -r
rpm -q kernel

uname -r should print the fixed NVR (name, version, release) or a later one, for example 5.14.0-687.64.1.el9_8.x86_64 on version 9. If rpm -q kernel lists the fixed version but uname -r shows an older one, you have not rebooted yet.

You can also look in the package changelog. rpm -q --changelog shows a package's change history:

rpm -q --changelog kernel | grep -i 'CVE-2026-98432'

If this prints a line, the changelog names the CVE. If it prints nothing, that tells you nothing either way. AlmaLinux's post does not say the changelog names this CVE, so comparing the NVR is still the real test. To find out what else on the box is unpatched, see how to check your server for known CVEs.

Ubuntu: wait for -updates, or install from -proposed?

On Ubuntu 22.04, 24.04 and 26.04, the fixed kernel is in -proposed. That pocket is where Canonical stages updates before release. Canonical moves them to -updates after qualification testing on more than 2,000 certified servers and devices. The Ubuntu kernel SRU cycle and when you have to reboot explains the usual timing of that process.

The choice depends on exposure. This bug is about servers that accept TCP connections from the internet, because the attack needs no login. If you run such a server and cannot wait, Canonical's own post gives the commands to pull only the kernel from -proposed. If the box sits behind a VPN or on a private network, waiting for -updates is the lower-risk choice, because a -proposed kernel has not finished that testing.

Before you install any kernel from -proposed, make sure you can open the server's console from your provider's panel. A kernel that does not boot leaves you without SSH. Keep the previous kernel installed so you can pick it from the boot menu. Read what to do when a VPS will not boot after a kernel update before you need it.

Install the Ubuntu kernel from -proposed

These are Canonical's commands, unchanged. First, enable the pocket for the main component and refresh the package lists:

sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update

Canonical notes that packages from -proposed are not selected for upgrade by default. Enabling the pocket does not upgrade anything by itself. You have to name the -proposed release when you install:

dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade

Read it from left to right. dpkg-query prints every installed package next to the source package it was built from. awk keeps only the packages built from a linux-meta source. Those are the meta-packages that pull in the current kernel, such as linux-generic or the equivalent for a cloud flavour. xargs passes that list to apt install. The -t option builds the target release name from your codename, for example noble-proposed. --only-upgrade tells apt to upgrade those packages and not install anything that was not already there.

Then reboot. Canonical says a reboot is required once the kernel security updates are installed.

sudo reboot

When the server is back, run uname -r and dpkg -l 'linux-image*' | grep ^ii again. The running kernel should now match the -proposed version for your release.

Remove the -proposed pocket afterwards

Canonical's post does not explain how to remove the pocket. The add-apt-repository man page documents how to remove repositories and components, but it does not mention pockets. So find the entry by hand:

grep -rn proposed /etc/apt/sources.list /etc/apt/sources.list.d/

On Ubuntu 24.04 and later, the sources are deb822 files in /etc/apt/sources.list.d/. That means the entry may be a word such as noble-proposed on a Suites: line, not a line of its own. Delete only that entry. Then run sudo apt update and repeat the grep to confirm it prints nothing. If apt starts warning about duplicate entries after your edit, the deb822 duplicate-sources error explains why.

Patch Rocky Linux and AlmaLinux

The fixed kernels are in the normal production repositories, so a regular update is enough. These are AlmaLinux's commands:

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

dnf clean metadata makes dnf download fresh repository data, so it sees the new kernel even when the cache is recent. Rocky Linux uses the same dnf commands, and its advisories carry the same kernel versions. After the reboot, uname -r should show the fixed NVR or a later one. Rocky's three advisories list the CVE, so a security-only dnf update also picks up the kernel if you would rather not upgrade everything. If you are not sure the reboot happened, needs-restarting tells you whether the running kernel is older than the installed one.

If you turned on AlmaLinux's testing repository to get an early build, turn it off again with sudo dnf config-manager --disable almalinux-testing.

Patch Debian

Confirm that your sources include the security suite. Then upgrade and reboot:

grep -rn security /etc/apt/sources.list /etc/apt/sources.list.d/
sudo apt update && sudo apt upgrade
sudo reboot

The grep should show a bookworm-security or trixie-security entry. If it prints nothing, the server never receives Debian's kernel security fixes. Fix that first. After the reboot, uname -v should show the fixed version.

Interim mitigations, and what each one leaves open

Use these only to cover the gap until you can reboot into a fixed kernel. Every vendor that publishes one says it is not a fix.

Drop inbound IPv4 TCP packets that carry IP options

ip hdrlength is the IPv4 header length, counted in 32-bit words. A header with no options is 5 words, which is 20 bytes. So ip hdrlength > 5 matches only packets that carry IPv4 options. Red Hat's version of the rule goes in a file named 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
    }
}

Check the file, load it, and list the table:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

The list command should print the rule with a counter packets value. A rising counter means the rule is dropping packets that carry options. The Ubuntu CVE page has a community-contributed rule with the same match, plus steps to load it from /etc/nftables.conf at boot. Canonical does not endorse it. AlmaLinux publishes its own version, in an ip cve_2026_98432 table on the prerouting hook.

The stated limits apply to all of these rules. The rule reduces the risk but does not fully prevent exploitation. It breaks any TCP connection that depends on IPv4 options. IPv6, and TCP options such as timestamps, are not affected. It covers the host only, so containers with their own network namespace need the rule applied inside that namespace. Red Hat's rule does not survive a reboot. If your firewall service loads a file that begins with flush ruleset, restarting that service deletes this table too. Run the list command again after any firewall reload.

When the fixed kernel is running, remove the rule:

sudo nft delete table inet cve_2026_98432

Turn off MPTCP and request migration

Akamai suggests two sysctls. These commands set them until the next reboot:

sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0

To keep them after a reboot, put both lines, net.mptcp.enabled = 0 and net.ipv4.tcp_migrate_req = 0, in /etc/sysctl.d/99-cve-2026-98432.conf. Then run sudo sysctl --system. Check the result with sudo sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req.

Akamai is clear about the limit: "Disabling MPTCP alone does not prevent exploitation; it only reduces the likelihood of triggering the race condition." Know what you are changing before you rely on it. The upstream kernel default for net.mptcp.enabled is 1, but Red Hat and AlmaLinux ship it set to 0. On a default RHEL system the sysctl therefore changes nothing, and Red Hat says those systems are still affected. The upstream default for net.ipv4.tcp_migrate_req is 0, so that line only matters if something on your server turned migration on.

sudo ss -lnMp lists listening MPTCP sockets. Red Hat warns that this only shows one known vulnerable configuration. An empty list is information, not reassurance. AlmaLinux adds that MPTCP listeners that are already open stay open until their services restart.

Go services listen with MPTCP by default

Go's documentation confirms that since Go 1.24, the multipathtcp setting defaults to "2", which turns on MPTCP for listeners. The reported exploit used an MPTCP listener, so the Go Security Team warned users on 29 October. A server built with Go 1.24 or later, on a host where net.mptcp.enabled is 1, can be an MPTCP listener without anyone choosing that. Setting GODEBUG=multipathtcp=0 for a program turns it off. The Go team calls disabling it program by program "a fragile mitigation" and recommends a patched kernel.

Does Livepatch cover CVE-2026-98432?

No primary source answers this yet. Canonical's -proposed post does not mention Livepatch, and the Ubuntu CVE page gives no Livepatch guidance for this CVE. The Livepatch page says "Canonical Livepatch is not a replacement for rebooting". If your server runs Livepatch, check what it has applied with canonical-livepatch status --verbose. Do not treat this CVE as covered unless it appears there. Live kernel patching on a VPS explains how live patches fit around normal reboots.

FAQ

Is my Ubuntu 24.04 VPS fixed for CVE-2026-98432 yet?

Not through normal updates, as of 7 November 2026. The Ubuntu tracker lists 24.04 as "work in progress" at linux 6.8.0-149.149, and Canonical says that version is in the -proposed pocket. Run dpkg -l 'linux-image*' | grep ^ii and uname -r. You are fixed only when 6.8.0-149.149 or later is installed and running. Cloud flavour kernels such as -aws have their own version numbers on the CVE page.

Does disabling MPTCP protect a server against CVE-2026-98432?

No. Canonical says the vulnerability is not specific to MPTCP, even though the reported exploit used an MPTCP listener. Akamai says disabling MPTCP only reduces the likelihood of triggering the race. On RHEL and AlmaLinux, MPTCP is already off by default, and Red Hat says those systems are still affected. The only complete fix is a patched kernel and a reboot.

Do I have to reboot after installing the patched kernel?

Yes. The fix is in the kernel, and the old kernel keeps running until the server restarts. Canonical says a reboot is required once the kernel security updates are installed, and AlmaLinux's instructions end with sudo reboot. When the server comes back, confirm with uname -r, or with uname -v on Debian.

Is it safe to run an Ubuntu kernel from the -proposed pocket?

It contains the same fix Canonical plans to release. It has not yet finished the qualification testing a kernel goes through before it moves to -updates. Install it only if the server is exposed and cannot wait. Make sure you have console access from your provider's panel and an older kernel to boot. Afterwards, remove the -proposed entry from your apt sources.