DEV Community

Cover image for CVE-2026-98432: Ubuntu Is Still Unpatched After 19 Days. How to Protect Servers
Alan West
Alan West

Posted on Originally published at blog.authon.dev

CVE-2026-98432: Ubuntu Is Still Unpatched After 19 Days. How to Protect Servers

#devops #linux #ubuntu #security

CVE-2026-98432 is a remote use-after-free in the Linux kernel's IPv4 TCP stack, rated CVSS 9.8. Debian shipped a fixed kernel one day after it went public. Ubuntu is now 19 days past disclosure, and as of today (November 3) every supported Ubuntu release from 16.04 to 26.10 still shows Vulnerable on Canonical's own tracker. That includes 22.04, 24.04 and 26.04 LTS, the HWE kernels, and the AWS, Azure, GCP and Oracle kernels. No ETA has been given.

If you run Ubuntu servers that accept TCP connections from the internet, the rest of this post covers the bug, how to check your boxes, and the nftables rule, sysctl settings and -proposed kernel I'm using while Canonical takes its time.

What CVE-2026-98432 breaks in the TCP handshake

It's a use-after-free in the IPv4 TCP handshake code. When a listener accepts a connection, tcp_v4_syn_recv_sock() hands the IP options (ireq->ireq_opt) to the child socket without copying them. If a retransmitted SYN shows up at the same moment, the kernel can read those options in ip_options_build() after the memory has been freed. Request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF SK_REUSEPORT migrate program) has a similar bug. The Debian tracker has the full description.

The bug arrived with commit 079096f103fa in Linux 4.4, released in January 2016. Eric Dumazet's fix, which swaps kfree() for kfree_rcu(), landed upstream on October 5 as e3f33b0a1d89. According to Akamai's write-up, the fixed stable releases are:

Branch First fixed
5.10 5.10.272
5.15 5.15.223
6.1 6.1.190
6.6 6.6.159
6.12 6.12.113
6.18 6.18.56
7.2 7.2.10
7.3 all releases

IPv6 isn't affected by the main path.

Is it really remote root, or is 9.8 overblown?

Both Hacker News threads (one, two) keep circling back to this, so I'll stick to what's actually been published.

The kernel CVE team scores it CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N), and Red Hat agrees on the number. On October 27 Anthropic's Frontier Red Team wrote that one of its models built a zero-click exploit that gets root commands against a host running an MPTCP listener. The exploit leaks a kernel pointer to defeat KASLR, then overwrites a callback pointer. A lost race only fails the handshake, so the attacker can keep retrying. Their proof of concept took about 48 minutes to leak the pointer and about five more to reach command execution. The exploit hasn't been released, and TuxCare says no independent public reproduction had surfaced as of October 30.

The skeptics' points, all from HN commenters: the CVSS 4.0 score Ubuntu uses for prioritization is lower (8.3), EPSS is under 1%, and two people who run edge routers counted zero inbound packets with IP options on their WAN links.

My take: "it needs MPTCP" isn't reassuring. Upstream defaults net.mptcp.enabled to 1, and the Go Security Team warned on October 29 that Go 1.24+ turns MPTCP on for listening sockets by default. So any Go service you deployed this year could be listening with MPTCP. The Go team and Red Hat's bulletin both say MPTCP isn't required for the bug itself; Red Hat adds that hosts with MPTCP disabled are still affected. As far as I'm concerned, a slow race that can be retried forever is still a working exploit.

Debian vs Ubuntu: the patch timeline Canonical has to explain

  • Oct 5: fix merged upstream
  • Oct 15: CVE published. Ubuntu's tracker entry is dated the same day.
  • Oct 16: Debian fixes trixie (DSA-6568-1, linux 6.12.113-1). Oracle fixes UEK.
  • Oct 17 / 22: Debian fixes bookworm (linux 6.1.190-1 in DLA-4841-1, linux-6.12 in DLA-4850-1)
  • Oct 24: kernel CVE team adds the 9.8 score, per TuxCare's timeline. Amazon fixes kernel6.18.
  • Oct 27: Anthropic publishes the exploit write-up
  • Oct 28: per one HN commenter, the 26.04 kernel moves to -updates/-security, with the other releases' fixed kernels sitting in -proposed. The tracker still lists 26.04 as work in progress, so check apt policy yourself.
  • Oct 29: SUSE publishes kernel advisories, and the Go Security Team publishes guidance.
  • Nov 3: Ubuntu tracker still shows "Vulnerable, work in progress"

The author of WTF Ubuntu? says Arch and Alpine have shipped fixes too, and quotes Ubuntu's server page promising "timely patches for critical vulnerabilities." They took their Ubuntu servers offline because they didn't have time to migrate first.

Writing for Canonical, HN user hcy-canonical said fixes for 22.04 and newer are in the -proposed pocket and "are being tested for stability." That's a reasonable process for a kernel that ships in dozens of flavours, and another commenter linked a regression report against the proposed linux-oracle build. But Debian runs a kernel with plenty of configurations as well, and it shipped in a day. In fairness, Red Hat had no fixed RHEL kernel either as of TuxCare's October 30 roundup, and one HN commenter put Ubuntu only about two days behind Red Hat, which gets far less heat. What makes Canonical's delay worse is that it sells Ubuntu Pro on exactly this promise.

Step 1: check if your Ubuntu kernel is vulnerable 

uname -r
pro fix CVE-2026-98432
Enter fullscreen mode Exit fullscreen mode

pro fix checks the installed packages against Canonical's data and tells you whether a fix is available. Right now the answer will be no. Compare your kernel with the in-progress versions listed on the tracker:

Release Package Fix in progress
26.04 LTS linux 7.0.0-43.43
24.04 LTS linux 6.8.0-149.149
24.04 LTS linux-hwe-7.0 7.0.0-43.43~24.04.1
24.04 LTS linux-hwe-6.17 none listed
22.04 LTS linux 5.15.0-203.213
22.04 LTS linux-hwe-6.8 6.8.0-149.149~22.04.1
20.04 / 18.04 / 16.04 linux none listed

Don't trust the version string on its own. Ubuntu backports fixes, so a number like 6.8.0 tells you nothing about upstream stable releases. Use the tracker.

Next, check how exposed you are:

sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -H -lMn          # any output = you have MPTCP listeners
Enter fullscreen mode Exit fullscreen mode

Step 2: does Livepatch or Ubuntu Pro cover it?

As far as I can find, no. The Ubuntu CVE page doesn't mention a Livepatch fix, and I found no Livepatch Security Notice for this CVE. Run canonical-livepatch status --verbose on a Pro machine to check yourself, but don't count on it. KernelCare has a rebootless patch for Debian 13, but lists Ubuntu as "Not available yet, no date."

Step 3: install a fixed kernel before Canonical ships one

There are three realistic options, roughly from least to most disruptive.

Install the kernel from -proposed

This kernel has the fix and is signed by Canonical, but it hasn't finished testing (remember the linux-oracle regression report). The EnableProposed wiki page points to the current Ubuntu docs. Name only the kernel metapackages so apt doesn't upgrade the rest of the system from -proposed:

sudo add-apt-repository -yp proposed
apt policy linux-image-generic     # confirm the -proposed candidate
sudo apt install -t noble-proposed linux-image-generic linux-headers-generic
Enter fullscreen mode Exit fullscreen mode

Change noble to jammy or resolute for your release. Try it on a staging box first, keep the old kernel in GRUB, and remove -proposed when the official update ships.

Switch HWE kernels?

Don't bother. Every HWE kernel still supported on 22.04 and 24.04 is listed as Vulnerable, so switching flavour won't get you a fix.

Move the workload

If the service runs in containers, the kernel is all that matters. A Debian 13 host on linux 6.12.113-1 or later runs your Ubuntu-based images without changes. Ubuntu's mainline kernel builds (7.3, or 7.2.10+) would also work, but they're unsigned, unsupported and break Secure Boot. I wouldn't put them on production.

Step 4: mitigate with nftables and sysctl until the patch lands

These are the mitigations Red Hat, Ubuntu's tracker and Akamai have published, and none of them fully closes the hole.

Drop IPv4 TCP packets that carry IP options

This is the rule from Red Hat's bulletin. Ubuntu's tracker shows a community-submitted nftables rule that does the same thing:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
Enter fullscreen mode Exit fullscreen mode 
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
# after patching:
sudo nft delete table inet cve_2026_98432
Enter fullscreen mode Exit fullscreen mode

I loaded this in a throwaway network namespace and it parses fine (nft prints the priority back as raw - 10). Normal TCP options are in the TCP header, so regular traffic shouldn't be affected, though anything that really depends on IPv4 options will break, as the Ubuntu page warns. Red Hat says the rule "reduces exposure" but "cannot fully prevent it." It also doesn't filter traffic in container network namespaces that bypass the host chain. The rule won't survive a reboot unless you include it from /etc/nftables.conf. Also, ufw won't save you: it's disabled on a fresh install, and its defaults don't cover this anyway.

Turn off MPTCP and request migration

This one is from Akamai's recommendations:

sudo tee /etc/sysctl.d/99-cve-2026-98432.conf <<'EOF'
net.mptcp.enabled = 0
net.ipv4.tcp_migrate_req = 0
EOF
sudo sysctl --system
Enter fullscreen mode Exit fullscreen mode

Restart services that already opened MPTCP listeners. For Go services, set GODEBUG=multipathtcp=0. That removes the setup the published exploit used, but Akamai is explicit that it only lowers the odds of winning the race and leaves the bug in place.

Filter at the edge

If you have a cloud firewall or load balancer in front of your hosts, drop packets with IP options there as well. One HN commenter says GCP already drops them. Check your own provider's documentation rather than taking a commenter's word for it.

Where I land

Pin the -proposed kernel on internet-facing boxes, add the nftables rule and the sysctl file today, and stop counting on Ubuntu LTS kernels for fast fixes. I'm not dropping Ubuntu over one CVE. But the next time I pick a container host OS, 18 days of Debian having a patch while Ubuntu had nothing will count against it.

Are you waiting for Canonical, swapping kernels, or using this as your excuse to leave Ubuntu? Tell me what you did with your fleet, especially if you think the 9.8 is overblown.

Sources

Top comments (0)