What Happened
CVE-2026-98432 is a use-after-free vulnerability (CWE-825, expired pointer dereference) in the Linux kernel's IPv4 networking code, publicly disclosed on October 15, 2026. It was assigned by the Linux kernel CNA and is now tracked by cve.org, Ubuntu, Red Hat, and the Debian Security Tracker. The bug lives in tcp_v4_syn_recv_sock(), the function the kernel uses when a TCP handshake finishes and a temporary "request socket" is turned into a real, established child socket. All three trackers agree on what the bug is. They do not agree on how dangerous it is in practice, which is the part worth understanding before deciding how urgently to react.
The Root Cause, in Plain Terms
When a client opens a TCP connection and includes IP options in its packet headers (an optional, rarely-used part of the IPv4 header), the kernel stores a pointer to those options on the temporary request socket while the handshake is in progress, as ireq->ireq_opt. Once the handshake completes, ownership of that pointer is supposed to move cleanly over to the new child socket, as newinet->inet_opt.
The problem is a timing gap in how that handover happens. tcp_v4_syn_recv_sock() transfers ownership of the IP options to the child socket without first copying them. If a retransmitted SYN packet for the same connection attempt arrives and is processed on a different CPU core at the same moment, it can travel through tcp_check_req() and trigger another SYNACK via tcp_v4_send_synack(). That code path reads ireq->ireq_opt while holding only an RCU read lock rather than a full lock, and the functions it calls further down — inet_csk_route_req(), ip_build_and_send_pkt(), ip_options_build() — read opt->optlen a second time. On a busy multi-core server, the first code path can free the memory while the second is still reading it.
This race has existed since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), which changed request sockets to be processed without the listener's lock held. The fix, merged upstream as commit e3f33b0a1d89d738e2b913dab519226eaf76e15b for kernel 7.3-rc7 and backported to the 6.8.y, 6.17.y, and 7.0.y stable branches, simply defers freeing the IP options until after an RCU grace period — guaranteeing no other CPU core can still be reading them when they are released.
9.8 or 5.9? Same Bug, Two Very Different Scores
If your monitoring or vulnerability scanner pulls CVSS data from different sources, you may see two very different severity numbers for this exact same CVE. Ubuntu's security tracker lists CVE-2026-98432 at CVSS 3.1 base score 9.8 with a "high" priority. Red Hat's CVE database lists the identical CVE at CVSS 3.1 base score 5.9, severity "Moderate." Same code, same upstream fix, two scores that look like different vulnerabilities.
The gap comes down to the CVSS vector string, not the underlying facts. Red Hat's published vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. Read it piece by piece: the flaw is reachable over the network (AV:N) with no privileges (PR:N) and no user interaction (UI:N) — so far that sounds alarming on its own. But two other parts of that vector change the picture. Attack Complexity is rated High (AC:H), meaning winning the race reliably is not trivial. And Confidentiality and Integrity impact are both rated None (C:N, I:N) — only Availability is rated High (A:H). In plain language, Red Hat's own scoring says a successful exploit can crash or destabilize the kernel. It does not read memory contents and it does not run attacker code.
Ubuntu's 9.8 reflects a different set of scoring assumptions for the same flaw, which is a known source of divergence when two organizations score CVSS independently instead of adopting a single shared number. The lesson is not "ignore the high score" — it is "open the vector string before reacting to the headline number." A 9.8 built on AC:H/C:N/I:N describes a very different real-world risk than a 9.8 built on AC:L/C:H/I:H, even though the two numbers look identical on a dashboard.
None of this makes the bug unimportant. Use-after-free issues are, as a class, unpredictable: a flaw that reliably causes a crash today can sometimes be refined into something more serious once the exact memory layout around it is better understood by whoever is looking at it. Based on what both vendors currently publish, this is a real kernel stability issue worth tracking and patching promptly once a fix ships for your distribution — not, today, a confirmed remote-code-execution or data-exposure emergency.
Distribution Status (as of publication)
As of this writing, no mainstream distribution has shipped a released fix. Here is where each stands:
| Distribution / Kernel | Status | Target fixed version |
|---|---|---|
| Ubuntu 18.04 LTS (bionic) | Needed — work not yet started | - |
| Ubuntu 20.04 LTS (focal) | Needed — work not yet started | - |
| Ubuntu 22.04 LTS (jammy), linux | Pending | 5.15.0-203.213 |
| Ubuntu 24.04 LTS (noble), linux | Pending | 6.8.0-149.149 |
| Ubuntu resolute, linux | Pending | 7.0.0-43.43 |
| Ubuntu stonking, linux | Pending | 7.3.0-10.10 |
| Ubuntu jammy, linux-hwe-6.8 | Needed — work not yet started | - |
| Ubuntu jammy, linux-aws | Pending | 5.15.0-1120.127 |
| Ubuntu noble, linux-aws | Pending | 6.8.0-1069.72 |
| Ubuntu jammy, linux-azure | Pending | 5.15.0-1126.135 |
| Ubuntu noble, linux-azure | Pending | 6.8.0-1073.82 |
| Ubuntu jammy, linux-oracle | Pending | 5.15.0-1117.123 |
| Ubuntu noble, linux-oracle | Pending | 6.8.0-1067.71 |
| Ubuntu, linux-gcp | Partially needed | - |
| RHEL 7, kernel / kernel-rt | Not affected | - |
| RHEL 8, kernel / kernel-rt | Fix deferred | - |
| RHEL 9, kernel / kernel-rt | Fix deferred | - |
| RHEL 10, kernel / kernel-rt | Fix deferred | - |
| OpenShift Container Platform 4 (CoreOS nodes) | Fix deferred | - |
| Debian bookworm (source package) | Tracked | 6.1.190-1 |
| Debian trixie (source package) | Tracked | 6.12.113-1 |
| Debian unstable (source package) | Tracked | 7.2.10-1 |
AlmaLinux and Rocky Linux rebuild their kernel packages directly from RHEL source, so both will carry the same "Fix deferred" status as RHEL 8, 9, and 10 until Red Hat ships an updated kernel erratum upstream.
What to Do Today
Since no distribution has a released fix yet, there is no single update command that resolves this. A few practical steps instead:
- Watch your kernel package, not just the CVE headline. Ubuntu, Red Hat (and by extension AlmaLinux/Rocky), and Debian are all tracking this CVE publicly — check for the specific fixed version listed above for your distribution and kernel flavor before assuming you are covered.
- If you use kernel livepatching, ask your provider directly. Several commercial and community livepatch services exist for both Ubuntu and RHEL-family systems. Check whether a patch for this specific CVE is available or planned — that is typically the fastest path to remediation without a reboot.
- Edge filtering of IP options is a reasonable hardening step, not a fix. Dropping or stripping inbound packets that carry IPv4 options at your network edge is a practice many operators already follow for unrelated reasons, and it does reduce exposure to this specific trigger path. It does not patch the underlying race condition in the kernel, so treat it as defense-in-depth alongside the eventual kernel update, not a substitute for it.
- If you run busy, multi-core servers handling real inbound TCP traffic — which describes most hosting infrastructure — this is one more reason to keep kernel patching on a predictable, tested cadence rather than deferring it indefinitely.
References
- Ubuntu Security Notices: ubuntu.com/security/CVE-2026-98432
- CVE.org / MITRE record: cve.org/CVERecord?id=CVE-2026-98432
- Red Hat CVE database: access.redhat.com/security/cve/CVE-2026-98432
- Debian Security Tracker: security-tracker.debian.org/tracker/CVE-2026-98432
- Upstream fix commit: git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b
Panelica's Sentinel keeps a running list of outstanding security updates like this one across the servers it watches, so you can see what is still pending without checking five different vendor trackers by hand.