The Linux Flaw That Shipped Its Fix Ten Days Before Anyone Named It
A race in the Linux IPv4 TCP handshake lets a stranger corrupt kernel memory with no login. Fixes are out for most distributions, but none of them count until the server reboots. Vendors scored it anywhere from 5.9 to 9.8, so check where it sits in your queue.
One SYN packet, sent twice. That is the whole attack. A race inside the Linux IPv4 TCP handshake lets a stranger corrupt kernel memory on a server listening on an open port, with no password and no clicks.
What Happened?
The Linux kernel CVE team published CVE-2026-98432 on October 15 and scored it 9.8 on October 24. It is a use after free in the code that sets up incoming IPv4 TCP connections. A client sends a SYN carrying IPv4 options, then resends it. Two CPUs race over the same block of memory. One frees it. The other reads what is no longer there.
Upstream had already quietly fixed it on October 5 with a two line patch. The bug goes back to kernel 4.4, which shipped in 2016. AWS put out a security bulletin on October 30 and updated it November 1, confirming that crafted packets to an affected listener can lead to unauthenticated remote code execution.
What Is the Impact?
Any Linux host with a reachable IPv4 TCP listener is in scope. Outcomes range from a kernel crash to memory disclosure to full corruption. Researchers showed remote code execution against hosts running a Multipath TCP listener, and Go services built on 1.24 or later can have that switched on without anyone asking.
Why Vendor Scores Disagreed
Here is the part that should worry you more than the flaw. Vendors could not agree on how bad it was. The kernel team said 9.8. One major vendor published 5.9 for two weeks, then raised it to Critical on November 1 when its fixes landed. Others sat at 8.1 and 7.0. Teams that sort a patch queue by vendor score alone left this one sitting.
One flaw. Five scores. A 3.9 point argument.
Every vendor looked at the same race condition in the Linux IPv4 TCP handshake and reached a different number. The gap is not academic. It decides which patch queue a server lands in, and how long it sits there.
Red Hat published 5.9 while the kernel team published 9.8. Teams that sorted by vendor score alone left this one in the backlog for two weeks. Exposure, not the number, is the real queue.
CVSS scores are not risk scores, and knowing every listener you expose beats any number on a tracker.
Where Patches Stand
Fixes are out for most major distributions. One of the largest still has nothing shipped as of November 2, and its oldest supported releases have no date at all. No exploitation in the wild has been reported, and the flaw is not in the CISA KEV catalog.
The fix shipped ten days before the CVE had a name.
Upstream landed a two line patch on October 5. The CVE arrived October 15. Three weeks on, where your servers stand depends entirely on which distribution you run.
- Amazon Linux 2 and 2023Kernel update plus reboot
- RHEL 8, 9 and 10Shipped Nov 1
- Debian Trixie and BookwormSecurity archive only
- SLES 15 and 16, Oracle UEKVendor advisories live
- Ubuntu 22.04 and 24.04Builds not released
- Ubuntu 26.04 and 26.10Builds not released
- AlmaLinux 8, 9 and 10Testing repository
- Rocky Linux 8, 9 and 10No errata published
- Ubuntu 16.04, 18.04, 20.04No date given
- RHEL 9 real time kernelStill listed affected
- OpenShift 4 CoreOS nodesStill listed affected
- Any kernel from 4.4 onwardBug is eleven years old
An installed kernel is not a running kernel. Compare what is on disk with what is booted, because this one does not take effect until the box comes back up. Status as published by vendors, November 2, 2026 · Verify your own tracker before acting
Are There Any IOCs?
None. No hashes, no domains, no attacker infrastructure. The bug lives inside your own kernel, so there is nothing to block at the firewall. Hunt behavior instead: kernel faults in the IP option build path, Multipath TCP listeners you did not know you had, and inbound SYN packets carrying Record Route or Timestamp options. A quiet log proves nothing, because a lost race can corrupt memory without crashing anything.
No indicators were published. Hunt the behavior instead.
There are no hashes, no domains and no attacker infrastructure to block for this one. It is a memory race inside your own kernel. What follows is what defenders can actually look at while the patch rolls out.
Search kernel logs on internet facing hosts for oops or panic traces naming ip_options_build, ip_build_and_send_pkt or skb_under_panic. Repeated faults on an exposed listener deserve a closer look.
Researchers demonstrated code execution against MPTCP listeners specifically. List them with ss -Mlnp. Watch for Go services built on 1.24 or later, where MPTCP can be on without anyone asking for it.
The trigger is a handshake packet carrying Record Route or Timestamp options. Normal traffic rarely uses them. Alert on inbound IPv4 packets where the header length exceeds 20 bytes, then drop them at the edge once you have tested the rule.
Confirm net.ipv4.tcp_migrate_req reads 0, and look for loaded reuseport migration BPF programs. Where patching has to wait, net.mptcp.enabled=0 narrows the path to code execution without fixing the bug.
Edge nodes that restarted for no recorded reason during the disclosure window are worth reviewing. So is any host where the booted kernel still trails the installed one after a patch cycle.
Detection buys you time. It does not close the hole. A kernel update followed by a reboot is the only complete fix, and every mitigation above is a holding pattern until that happens.
How to Avoid This
Patch and Reboot
- Update the kernel, then reboot. Nothing counts until it comes back up.
- Patch internet facing listeners first, then work inward.
- Compare the booted kernel against the installed one.
If You Cannot Patch Yet
- Set
net.mptcp.enabledto 0 while you wait for a fix. - Drop inbound IPv4 packets carrying options at the edge, after testing.
Ten Days to a Name. How Long to Find Every Host?
The hard part was never the patch. It was knowing which boxes are exposed, which rebooted, and which quietly did not. That work is where remediation SLAs go to die.
Secure.com AI Teammates work above the stack you already own:
- Map every reachable IPv4 TCP listener across cloud and on premise, continuously.
- Validate what is actually exploitable in your environment instead of ranking by vendor score.
- Open and route remediation work to the owner who can act on it.
- Retest after the reboot and keep the before and after as evidence.
- Hold consequential actions at an approval gate your team controls.
Attack. Harden. Prove. Repeat.
