The anger in “WTF Ubuntu?”, published on 2 November, has a concrete trigger: a critical Linux TCP vulnerability, a fix elsewhere in the distribution ecosystem and Ubuntu kernel entries still marked vulnerable. The post's timestamp is useful because patch availability is a moving fact. The operator reading it needs to establish the state of a particular machine now.
CVE-2026-98432 is a serious problem. Understanding it requires keeping the vulnerability, the demonstrated exploit and the distribution's package status in view at the same time. Each answers a different part of the exposure question.
What failed in the kernel
The Debian security tracker's technical description describes a use-after-free involving IPv4 options during TCP connection handling. Ownership and lifetime become inconsistent: one path can free memory while another still uses it. The upstream repair defers freeing the relevant objects until readers have passed the appropriate RCU grace period.
This is a kernel memory-lifetime problem. Rewriting an application's input validation does not establish that its host has received a repaired kernel. The operating system's networking path sits below the application that eventually accepts a connection.
It is also worth keeping the terminology straight. IPv4 options and TCP options occupy different protocol layers. A mitigation aimed at one cannot be casually translated into an instruction about the other merely because both appear in a discussion of TCP traffic.
The research exploit has a stated target
In its 27 October research report, Anthropic describes a proof of concept against a Linux server with a multipath-TCP listener. It reports remote command execution as root without credentials or user interaction. The report says the vulnerability was fixed upstream and backported to maintained stable kernel branches.
That is a substantial claim from the researchers who developed the demonstration. It should retain the target description when repeated. “A working exploit was demonstrated against this setup” is more informative than dropping the setup and declaring every Linux installation equally exploitable.
Equally, the demonstrated configuration is not an exhaustive statement of every vulnerable configuration. Operators should use their vendor's vulnerability assessment for the affected code and package, rather than treating the research example as a complete list of conditions under which the bug could matter.
A proof of concept establishes a research result. It does not supply a count of malicious compromises in production. A report can treat the first as urgent without inventing the second.
Debian's fix is a package fact with a date
Debian's DSA-6568-1, issued on 16 October, lists CVE-2026-98432 among the kernel issues fixed for its stable trixie distribution in source version 6.12.113-1. The live tracker provides the release-specific status and subsequent fixed-package information.
That supports the central comparison in the Ubuntu criticism: a vendor package fix was already published. It does not mean a package from another distribution can simply be substituted into an Ubuntu installation, or that a machine identifies itself as fixed merely because its version string looks newer.
Distribution kernels carry their own patches and revisions. The evidence an administrator needs is the vendor's assessment of the actual installed package and kernel flavour. Comparing only the first part of two version numbers loses information that the security tracker exists to provide.
Ubuntu's table still requires a machine-specific answer
When checked on 4 November, Ubuntu's CVE page, last updated on 3 November, rated the issue critical with a CVSS 3 score of 9.8. Its standard linux package entries included:
| Release | Status shown at the check |
|---|---|
| Ubuntu 26.04 LTS | Vulnerable; work in progress |
| Ubuntu 24.04 LTS | Vulnerable; work in progress |
| Ubuntu 22.04 LTS | Vulnerable; work in progress |
The page separately lists cloud, hardware-enablement, OEM and other kernels. A standard-kernel row cannot stand in for every one of them. Entries labelled as work in progress must also be distinguished from a released fix that the vendor says is available.
The criticism concerns the gap between an upstream repair and a deployable vendor repair. That gap is meaningful even if an engineering team has a patch under preparation. An operator can deploy an available, supported fix; a planned package revision is information for a decision, not evidence that the machine is repaired.
The suggested filtering is explicitly partial
Ubuntu documents filtering IPv4 TCP packets that contain IPv4 options, assuming those options are unnecessary for the environment. It says this reduces risk without fully preventing exploitation. It also notes that separate container networking needs separate treatment and that TCP timestamps, window scaling and IPv6 are unaffected by that particular filter.
Those qualifications should travel with any recommendation. Applying a fragment of a firewall example without its assumptions can change availability while leaving a reader with an exaggerated sense of protection. The actual firewall manager, network namespaces and required traffic all belong in the change review.
For an affected service, the practical decision is how to reduce exposure while obtaining a supported fix. That might include restricting reachable services or changing where a workload runs. The choice depends on the service and its dependencies; the advisory supplies evidence for the decision rather than a universal command to paste onto every server.
Record the state you can verify
A useful operations note identifies the host, release, kernel flavour, package revision, running kernel and advisory status at a stated time. A running-version check such as uname -r is one observation in that record. It still needs vendor context for backports and any applicable livepatch status.
Keep temporary network controls and the final repair as separate tracked items. Name who will check the vendor's status again, who can authorise the deployment and what confirms that the intended repaired kernel is actually in use. That avoids closing a risk merely because somebody successfully downloaded a package.
The immediate question raised by the Ubuntu post survives the heat of its language: what supported protection is available for this machine today? Answering it accurately means preserving the advisory's details, the check time and the distinction between a fix that exists upstream and one the operator has actually put into service.
A thought worth keeping?
