# Ubuntu 22.04, 24.04 and 26.04 kernels remain unpatched for CVE-2026-98432 at CVSS 9.8

> Ubuntu has no fixed kernel and no ETA for a CVSS 9.8 kernel bug across three LTS releases. Here is what practitioners are using in the interim on exposed GPU and inference hosts.

- Published: 2026-11-03
- By: Samir Sengupta (https://www.samcodeman.com/about)
- Canonical: https://www.samcodeman.com/writing/ubuntu-lts-kernels-unpatched-cve-2026-98432
- How this was made: Drafted with Claude, Anthropic's model from 1 cited source, then checked against it in a second editing pass. Editorial policy: https://www.samcodeman.com/editorial-policy

## The short version

- As of an October 31, 2026 report, Ubuntu had shipped no fixed kernel for 22.04, 24.04 or 26.04 LTS against CVE-2026-98432, rated CVSS 9.8, and had announced no ETA.
- The interim mitigation posted on Hacker News is an iptables u32 rule. On the INPUT chain it drops inbound TCP packets whose IPv4 header carries options.
- A commenter quoting Red Hat's bulletin said Red Hat's mitigation 'reduces exposure to this vulnerability but cannot fully prevent it'. Another commenter said that mitigation only filters traffic to the host network namespace.
- The sources do not give affected kernel package versions, module blacklisting or sysctl options, HWE or mainline status, or Livepatch coverage.

As of an October 31, 2026 report, Ubuntu had not shipped fixed kernels for CVE-2026-98432 on its 22.04, 24.04 or 26.04 LTS releases. The vulnerability is rated CVSS 9.8, and the report's headline calls it a Linux 0day RCE. Ubuntu has not announced an ETA for the fixes. Until packages appear, administrators can stay on the stock kernel, apply out-of-tree mitigations if any exist, or move workloads onto releases or kernels that already carry the patch.

The vendor-status claim comes from a freenode.net article dated October 31, 2026, headlined 'Ubuntu still has not released patch for Linux 0day RCE in almost 3 weeks'. The article covers vendor status and gives no technical detail. The operational detail below therefore comes from a Hacker News thread and is attributed to commenters there. One commenter warned that today's freenode.net is not the IRC network many engineers remember and is not a real news source, while allowing that its claim might be true, so check the status against Ubuntu's own security notices.

## Which Ubuntu LTS releases are exposed to CVE-2026-98432

The source names three releases with no vendor fix: 22.04, 24.04 and 26.04 LTS. It does not list specific kernel package versions. It does not say which flavours are affected, such as generic, HWE or cloud-optimised kernels. It does not say whether older releases under extended support are affected. The source says the risk is highest on internet-facing and multi-tenant self-hosted systems that rely on Ubuntu's LTS kernels for isolation and privilege boundaries.

GPU inference hosts fit that description when they are internet-facing or shared between tenants. Examples are model servers exposed to the network, or Kubernetes nodes where workloads are separated by namespaces. On those machines the kernel is the isolation boundary, so a kernel RCE puts every workload on the host in scope.

## What an attacker needs to reach the RCE

The freenode article does not say whether the attack is remote or local. It refers only to 'whatever remote or local attack the CVE enables.' On Hacker News, one commenter referred to monitoring for 'corrupt IP options packets', and another posted a filter that drops packets carrying IPv4 options. If that reading is right, the attack surface is the kernel's handling of incoming packets rather than any particular listening service.

That bears on one argument in the thread. One commenter urged people to stop running services they do not need, such as dhcpcd and avahi, and to run a firewall. Another replied that the CVE has nothing to do with leaving random ports open and that tightening up will not protect vulnerable servers. Neither source confirms whether authentication, network adjacency or a specific protocol is required to trigger the bug.

## The iptables u32 rule drops TCP with IP options

The most concrete interim mitigation in the thread is a single iptables rule posted by one commenter. The u32 match reads the first 32-bit word of the IPv4 header and shifts it right by 24 bits, which keeps only the first byte. It then masks the low nibble, which is the IHL (header length) field. Any packet with a header length of 6 to 15 32-bit words is dropped, which means any IPv4 packet carrying options.

```bash
iptables -A INPUT -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP
```

- As written, the rule matches only -p tcp. UDP and ICMP packets with IP options are not dropped by it.
- It sits on the INPUT chain, so it applies to packets addressed to the host itself. Traffic forwarded to containers or pods traverses other paths.
- It uses -A (append), so an earlier ACCEPT rule in the chain will take precedence. Teams should check rule order.
- iptables rules apply to IPv4 only. The sources do not say whether an IPv6 path to the bug exists.

On a Kubernetes GPU node, those scope limits decide whether the rule helps at all. Inference pods with their own network namespaces are not covered by a host INPUT rule. Covering them needs equivalent filtering on the FORWARD path or in the CNI's policy layer, and the sources do not give a tested rule for either.

## Red Hat's mitigation reportedly cannot fully prevent it

Commenters noted that Ubuntu has published no mitigation possibilities or instructions. One commenter linked a Red Hat security bulletin that does describe a mitigation, but quoted a caveat from it that they found unexplained:

> reduces exposure to this vulnerability but cannot fully prevent it
>
> - Red Hat security bulletin, as quoted by a commenter on Hacker News

A reply said the bulletin does elaborate, describing it as a network namespace scope statement. According to that commenter, Red Hat's rule only filters traffic to the host network namespace. Pod-to-pod traffic is untouched, and filtering of traffic forwarded to pods depends on the cluster network configuration. The same limit would apply to the host INPUT rule above, so on container hosts a packet filter lowers risk on the host interface and only a patched kernel removes it.

One commenter also said RHEL did not release a patch until the day before their post. The thread does not give a date for that post.

## Proposed kernels reportedly carry the fix; Livepatch unknown

One commenter reported seeing another user successfully update their kernel from Ubuntu's 'proposed' branch, which they said already has the fix, and asked why it had not been merged into stable. The commenter did not say which release or kernel version was involved. The sources say nothing about what testing that branch has had. A GPU host should take any such kernel on a single node first, with the GPU driver modules rebuilt and checked against it, before it goes across a fleet.

The sources say nothing about HWE kernels, mainline kernel builds, Livepatch coverage, module blacklisting or sysctl settings for this CVE. No module name, sysctl key or Livepatch status should be assumed until Ubuntu publishes one. Commenters did mention other platforms. One said Gentoo-based CI/CD systems were patched as early as any other system. Another asked whether ucore had a patch yet after moving off Ubuntu to it. A third pointed to HardenedBSD as the reason some systems run it instead of Linux.

## What GPU inference hosts can do before a fix

1. Inventory every host on 22.04, 24.04 and 26.04 LTS, starting with internet-facing and multi-tenant nodes.
2. Apply the IP-options drop rule on the host INPUT chain. Then look at forwarded and pod traffic through the CNI, because a host INPUT rule does not reach other network namespaces.
3. Consider dropping IP-options packets for UDP and ICMP as well, after checking that no workload depends on them. The sources do not discuss side effects.
4. Evaluate the proposed-branch kernel on a canary GPU node, including driver rebuilds, as a bridge to the stable fix.
5. Watch Ubuntu's security notices for the fixed package versions and for any Livepatch coverage, which the sources do not mention.

One commenter said they had at least 20 unpatched servers, had seen no exploit in the wild, and thought the risk was blown out of proportion. They added that a number of mitigation options were available, without naming them. A reply asked how they would see an exploit without honeypots or monitoring for corrupt IP options packets, and argued that most people who get hacked will not know how it happened. Given a CVSS 9.8 rating and no vendor ETA, not having seen exploitation is weak evidence. For shared GPU infrastructure, the filter plus a tested path to a patched kernel is the defensible position.

## Questions this raises

### Which Ubuntu releases are still unpatched for CVE-2026-98432?

According to an October 31, 2026 report, Ubuntu 22.04, 24.04 and 26.04 LTS had no fixed kernels and no announced ETA. The source does not list specific kernel package versions or say which flavours, such as HWE or cloud kernels, are affected.

### Does the iptables IP-options rule fully protect Kubernetes GPU nodes?

No. The rule as posted matches only TCP on the host INPUT chain, so UDP, ICMP, IPv6 and traffic forwarded to pods in their own network namespaces are not covered. Covering pods needs equivalent filtering on the FORWARD path or in the CNI policy layer, and the sources give no tested rule for that.

### Is there a kernel with the CVE-2026-98432 fix available for Ubuntu?

One Hacker News commenter reported that Ubuntu's proposed branch already has the fix, but did not say which release or kernel version was involved. The sources say nothing about its testing, so GPU hosts should trial it on a single canary node with driver modules rebuilt before rolling it out.

## Key facts

- CVE-2026-98432 is rated CVSS 9.8 and is described in the source headline as a Linux 0day RCE.
- As of an October 31, 2026 report, Ubuntu 22.04, 24.04 and 26.04 LTS had no fixed kernel and no announced ETA.
- A commenter's iptables u32 rule drops IPv4 packets with a header length of 6 to 15 words, but only for TCP on the host INPUT chain.
- Red Hat's bulletin says its mitigation reduces exposure but cannot fully prevent the bug, because it filters only the host network namespace.
- One commenter reported that Ubuntu's proposed branch already carries the fix, without naming the release or kernel version.

## Sources

1. [Ubuntu still has not released patch for Linux 0day RCE in almost 3 weeks](https://freenode.net/article/ubuntu-lts-kernels-still-unfixed-for-critical-cve-2026-98432) - freenode.net

Discussion read (practitioners' reactions, not a source): https://news.ycombinator.com/item?id=50341462