One Bug, Four Scores: Reading CVE-2026-98432, the Linux TCP Use-After-Free
The Hacker News ran a headline this week about a Linux kernel TCP flaw with a 9.8 CVSS. I upgraded my machines first, then read the advisories properly. The interesting part is not the number. It is that four vendors looked at the same bug and published four different scores.
This post covers the mechanism, why the scores disagree, the patch status as of 29 October 2026, and what I did about it. I am working from vendor trackers and the press coverage. I have not reproduced the bug, and I am not going to.
What the bug is
CVE-2026-98432 is a use-after-free in IPv4 TCP connection setup. The upstream fix is titled “ipv4: free inet_opt and ireq_opt after an RCU grace period”, which tells you most of the story.
When a TCP handshake completes, the kernel turns the pending connection request into a full socket. The request carries any IP options the client sent, such as Record Route or Timestamp. The new socket takes over those options without copying them. If that socket is destroyed while another CPU is still using the same options to answer a retransmitted SYN, the second CPU reads freed memory.
Three details matter for how worried to be:
- It is a race. One CPU has to lose to another, so an attacker needs to retry.
- It is IPv4 only. IPv6 copies its options, so it does not have this problem.
- It is old. The bug was introduced in Linux 4.4, so it has been in the tree for a long time.
The fix makes the kernel wait for an RCU grace period before freeing the options, so no other CPU can still be reading them. Upstream stable fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.
Four vendors, four scores
The kernel CNA scores it 9.8. Red Hat’s CVE page says 5.9, while its machine-readable advisory says 8.1. Oracle and SUSE say 8.1. Amazon says 7.0.
The coverage did not publish full vectors, so this is my reading of the standard CVSS 3.1 arithmetic rather than a quote from any vendor. A network-reachable bug with no privileges, no user interaction and full impact on confidentiality, integrity and availability scores 9.8 when attack complexity is Low. Change only attack complexity to High and the same vector scores 8.1. The reports say the kernel team and the 8.1 vendors differ on exactly that one metric.
So the argument is about whether a race counts as high complexity. Both sides have a case:
- For High: the attacker has to win a timing window against another CPU. That depends on conditions outside their control, which is what the High rating is for.
- For Low: a failed attempt does not crash the machine, so the attacker can retry as often as they like. The race costs time, not luck.
The retry point is the one I find most convincing, and it matches what Anthropic reported (below). A race you can rerun indefinitely without penalty behaves like a deterministic bug with a slow success rate. Complexity measures how much the attacker depends on conditions beyond their control, and an unlimited retry loop reduces that dependence.
The practical lesson for anyone triaging from scores: a 5.9 on one page and a 9.8 on another does not mean someone made a mistake. It means the inputs to the formula were judged differently. Read the vector, not the number, and decide for yourself which attack complexity matches your exposure.
The part about Claude
Anthropic researcher Xinyang Ge is credited with reporting the bug. Anthropic says its Claude model wrote a working exploit after initial prompting. By Anthropic’s account, the exploit targeted servers with a multipath TCP (MPTCP) listener. A first stage leaked a kernel address to defeat KASLR, and a second overwrote a callback pointer to run a command as root. In their test, the address leak took 48 minutes and command execution took 5 more.
Anthropic did not publish exploit code, the kernel version or the test configuration. The coverage also does not say whether servers without MPTCP can be exploited the same way, and I would not assume either answer. I also cannot say whether turning MPTCP off reduces risk, so treat checking sysctl net.mptcp.enabled as information, not as a mitigation.
I use Claude to help run this blog, and I wrote about how that works, so I will say plainly that this story sits close to home. It also lands neatly on the argument from my AI Pentest Agents series: the exploit is the part machines are getting good at, and the judgment about what to do with it is still ours. Cisco made a similar admission about vulnerability discovery in its August hardening advisory.
As of 29 October there were no reports of attacks using this flaw, and it was not in the CISA KEV catalog copy I could see.
Patch status
Status differs a lot between distributions, which is the other thing worth noting:
| Distribution | Status on 29 October |
|---|---|
| Debian 13 (trixie) | Fixed, DSA-6568-1, linux 6.12.113-1 |
| Debian 12 (bookworm) | Fixed, DLA-4841-1 (6.1.190-1) and DLA-4850-1 (6.12.113-1~deb12u1) |
| Oracle Linux 7 to 10 (UEK) | Fixed on 16 October |
| Amazon Linux 2023 | Fixed on kernel 6.18 and 6.12 packages, other packages pending |
| SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Fixed |
| SLES 15 and 16, SLE Micro 5.x | In testing or in progress |
| RHEL 8, 9, 10 | Fix deferred, no advisory |
| RHEL 7 | Not affected |
| Ubuntu 22.04 to 26.10 | Work in progress, no advisory |
| Ubuntu 16.04, 18.04, 20.04 | Vulnerable, no advisory |
Debian fixed this on 16 October. RHEL and Ubuntu had nothing shipped nearly two weeks later. Red Hat also says no available mitigation meets its bar for being easy to deploy, broadly suitable and stable, so for RHEL users the answer today is “wait for the kernel”.
That gap is the same theme as my posts on the Ted backdoor in a recompiled HAProxy and checking two servers for the eMudhra certificates: the version you think you run and the version you actually run are different questions, and the answer depends on your distribution’s pace, not the upstream announcement.
What I did
My machines are Debian-based, so the fix was already available:
sudo apt update && sudo apt full-upgrade -y && sudo rebootAfter the reboot, uname -r should report 6.12.113 or later on trixie. The reboot matters, because a kernel package that is installed but not running protects nothing. My NatJack test VM was on 6.12.101, so it was behind the fix, which is a fair reminder that a lab VM you rarely touch ages quietly.
My exposure is lower than a typical server because my public services sit behind an outbound-only tunnel with no port-forwards, so nothing listens for a remote attacker to reach. I patched anyway, because the fix costs one reboot.
Takeaways
- Read the CVSS vector, not just the score. Attack complexity alone moved this bug from 9.8 to 8.1.
- A race you can retry for free is closer to Low complexity than it first looks.
- Kernel fixes need a reboot to count.
- Distribution patch lag is real. Check your own vendor’s tracker, not the upstream announcement.
If you want more on how the kernel is trying to stop whole bug classes at the source, I covered the removal of strncpy in Linux 7.2 and the September kernel CVE round-up. Use-after-free bugs of this kind are the class that memory-safe languages and RCU discipline are meant to eliminate, and they keep turning up in code that is a decade old.
Sources: The Hacker News, Debian Security Tracker, Red Hat Bugzilla 2553390.