If you run a self-hosted server on Ubuntu or RHEL, the CVE that just hit the Linux kernel is a sharp reminder of a very specific trap: a new kernel version number is not the same thing as a patched server. CVE-2026-98432 is a remote, unauthenticated use-after-free in the Linux IPv4 TCP stack, rated 9.8 (Critical) by the kernel’s own CVE team and cve.org.[1] Upstream fixed it in stable kernels from 5.10.272 up to 7.3.[1][5] But as of November 1, 2026, Ubuntu and Red Hat Enterprise Linux have not shipped a fixed kernel - Ubuntu lists its supported releases as “Vulnerable / work in progress”, and Red Hat is still expediting the fix.[2][3][4] On those systems uname -r will happily print a perfectly modern kernel that is still vulnerable. This article explains the bug, why the version on your screen lies, and the exact steps to take before (and after) the kernel patch lands.

The bug: a freed option read during the IPv4 TCP handshake

CVE-2026-98432 is a race condition in how the kernel hands off connection state during a TCP handshake.[1] In tcp_v4_syn_recv_sock(), the kernel transfers ownership of ireq->ireq_opt (the IP options of an incoming connection request) to the child socket without copying it.[1] Meanwhile, on another CPU, a retransmitted SYN for the same request socket can be processed, and tcp_check_req() can send a SYNACK that reads ireq->ireq_opt again.[1] Since commit 079096f103fa (“tcp/dccp: install syn_recv requests into ehash table”), request sockets are processed without holding the listener lock - so nothing stops the child socket from being freed while the SYNACK is still being built.[1] TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), so the concurrently-running path ends up reading memory that was already freed - a classic use-after-free in ip_options_build().[1]

There is a second trigger via request-socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program), where a cloned request socket and its clone share the same ireq_opt, and the clone can be freed while another CPU still holds a reference on the old one.[1] The fix changes the plain kfree() calls in inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu(), so the memory is only reclaimed after an RCU grace period - by which point every reader is done.[1][5] IPv6 is not affected by the first issue (the v6 path duplicates the options), though a separate migration issue is being addressed in a separate patch.[1]

The affected code path has been present since Linux 4.4.[1] Crucially, it is reachable over ordinary, unauthenticated IPv4 TCP traffic: Red Hat notes the attacker needs no privileges and no user interaction and can be on the network, which is why it is rated Critical in enterprise configurations where TCP services accept incoming connections by default.[3][4]

Why uname -r lies to you

Here is the part that trips up most VPS owners. The upstream kernel fixed this 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 - the versions cve.org lists as “unaffected” for each stable branch.[1][5] But practically no one boots a raw upstream kernel. You boot your distribution’s kernel, and it carries its own version string and its own patch status that has nothing to do with the upstream release numbers.[2][3] uname -r reports the running kernel; it does not report whether the CVE is fixed by your vendor. And in this case, as of November 1, 2026, the two biggest hosts of self-managed servers sit squarely in the vulnerability window:

  • Ubuntu 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS: “Vulnerable - work in progress”. Ubuntu’s security tracker shows the fix as introduced by commit 079096f and resolved by e3f33b0, but no fixed kernel (and no Ubuntu Security Notice) is published for any currently-supported release; 20.04 and 18.04 remain “Vulnerable” too.[2] Note that Ubuntu rates this 8.3 (High) under CVSS v4.0, while the kernel team and cve.org score it 9.8 (Critical) under v3.1 - same bug, different scoring rules, which is another layer of confusion worth ignoring.[1][2]
  • Red Hat Enterprise Linux 8, 9 and 10: affected, fix not yet released. Red Hat’s bulletin RHSB-2026-016 (published 30 October) rates it Critical, lists RHEL 8/9/10 and OpenShift as directly affected, and states Red Hat is “expediting the release of fixes”.[3][4] The mitigation below is Red Hat’s own documented interim measure.
  • Debian 12 and 13: patched. Debian shipped fixed kernels - 6.1.190-1 for bookworm, 6.12.113-1 for trixie, and 6.12.113-1~deb12u1 for bookworm’s opt-in 6.12 kernel (advisories DLA-4841-1, DLA-4850-1, DSA-6568-1).[6]
  • SUSE: mixed. SUSE’s own CVSS v4.0 score is 9.2 (vector with Attack Requirements = Present - stricter than Ubuntu’s 8.3). Product states differ: fixed kernels are already Released for SUSE Linux Enterprise Micro 5.3–5.5, SLE High Availability Extension 16.0 and HPC 15 SP5-LTSS, while on SLED/SLES 15 SP7 the kernel-source package is still In progress and kernel-default itself is Affected.[7]

So the answer to “what kernel keeps me safe” is not a version number you can google - it is the status your distribution publishes for this specific CVE, and it changes daily.[2][3][7]

What to do right now, before the kernel patch lands

Until your distribution ships the fixed kernel, your exposure is reduced (not eliminated) by filtering out the dangerous traffic. For RHEL (and generally any nftables-based host), Red Hat’s security bulletin documents an nftables table that drops incoming IPv4 TCP packets carrying IP options - the exact option-handling path that the use-after-free touches.[4] Normal application traffic is generally unaffected because standard TCP options live in the TCP header and remain permitted, but Red Hat explicitly warns to review the rule against your own traffic and test it in a non-production environment first.[4]

Save this to a file named cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Then load it with nftables’s own check-and-load commands from the bulletin:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

To remove it later (for example, once you have booted the patched kernel):[4]

sudo nft delete table inet cve_2026_98432

Two more interim steps are worth doing on any host you do not explicitly need to expose:

  • Disable MPTCP where you do not use it. The security community has been publicly discussing this CVE hard since late October, with reports describing a working remote-root exploit chain against hosts that expose a multipath-TCP listener.[8] This is community-reported guidance, not part of Red Hat’s or the kernel CNA’s official mitigation, so treat it as extra hardening: if you have no MPTCP-based workload, shutting off the net.mptcp.enabled path removes a widely-discussed trigger surface. (Neither the CVE record nor Red Hat’s bulletin documents MPTCP in its official mitigations, so a filter is not a substitute for the kernel fix.)[1][4]
  • Remember your containers share the host kernel. The fix is in the kernel, not in any container runtime or base image. If your app runs in Docker, upgrading the image changes nothing until the host kernel is patched and (see below) rebooted.

The kernel update is not complete until you reboot

This deserves its own section, because it is the most common reason a “patched” VPS actually is not patched. A kernel update on Ubuntu or RHEL installs the new kernel image but does not swap it into the currently-running system - the old, vulnerable kernel keeps running until you reboot (or run a live-patching product, which is a separate deployment). The sequence that actually closes the hole is:

  1. Check your running kernel against your distribution’s CVE status, not the upstream version list: uname -r, then compare with your tracker’s fixed-version column.[2][3][6]
  2. Apply apt upgrade (Ubuntu/Debian) or the RHEL update once the advisory ships.[2][3]
  3. Reboot and verify the new kernel is actually running (uname -r again).
  4. If you applied the nftables filter, you can drop it once the running kernel matches the fixed version.

Until step 3 happens, the CVE is not closed, no matter how the package manager’s output reads.

The bigger lesson for self-hosting

Every self-hosted VPS on Ubuntu or RHEL that accepts inbound IPv4 TCP connections is sitting in this CVE’s blast radius right now - the same kernel you depend on for a public website, an API, a database socket or SSH is the code path under attack.[3][4] The durable takeaway is the one this bug is built to teach: a kernel’s patch status is a property of your distribution’s tracker, not of the upstream version string on your screen. When you see a CVE with a remote, unauthenticated, “Critical” rating, the reflex of “check my version” is wrong - the reflex that saves you is “check my distribution’s status for this CVE, then make sure the running kernel actually changed.” Combined with the interim nftables filter, disabling MPTCP you do not use, and an explicit reboot step, that converts a scary advisory into a short, verifiable checklist on a server you control.

Sources

  1. CVE.org - CVE Record for CVE-2026-98432 (published 2026-10-15; description of the IPv4 use-after-free and kfree_rcu fix; CVSS 3.1 base 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; affected from 4.4 / commit 079096f103fa; “unaffected” from 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3; stable-commit references). https://www.cve.org/CVERecord?id=CVE-2026-98432 - checked 2026-11-01
  2. Ubuntu - CVE-2026-98432 security tracker (release status: 26.10/26.04 LTS/24.04 LTS/22.04 LTS “Vulnerable work in progress”, 20.04/18.04 “Vulnerable”; patch details introduced by 079096f, fixed by e3f33b0; CVSS v4.0 base 8.3 High). https://ubuntu.com/security/CVE-2026-98432 - checked 2026-11-01
  3. Red Hat Customer Portal - CVE-2026-98432 (Critical; CVSS 3.1 base 9.8; unauthenticated remote attacker, no privileges or user interaction; RHEL 8/9/10 affected; mitigation pointer). https://access.redhat.com/security/cve/CVE-2026-98432 - checked 2026-11-01
  4. Red Hat Security Bulletin - RHSB-2026-016 “Use-after-free - kernel IPv4 (CVE-2026-98432)” (published 2026-10-30; rated Critical; affected products RHEL 8/9/10, OpenShift, and RHEL-kernel layers; expediting fixes; nftables mitigation table inet cve_2026_98432 with hdrlength > 5 drop and the sudo nft --check/--file/list/delete table commands). https://access.redhat.com/security/vulnerabilities/RHSB-2026-016 - checked 2026-11-01
  5. Linux kernel - mainline fix commit e3f33b0a1d89 “ipv4: free inet_opt and ireq_opt after an RCU grace period” (resolved in 7.3-rc7; changes kfree() to kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(); commit ID cross-referenced by cve.org, Ubuntu and Debian trackers). https://git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b - checked 2026-11-01
  6. Debian Security Tracker - CVE-2026-98432 (bookworm linux 6.1.190-1 fixed via DLA-4841-1; bookworm linux-6.12 6.12.113-1~deb12u1 via DLA-4850-1; trixie linux 6.12.113-1 fixed via DSA-6568-1). https://security-tracker.debian.org/tracker/CVE-2026-98432 - checked 2026-11-01
  7. SUSE - CVE-2026-98432 (SUSE’s own CVSS v4.0 base 9.2, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H; per-product states: fixed kernels Released for SLE Micro 5.3–5.5, SLE HA Extension 16.0, HPC 15 SP5-LTSS; SLED/SLES 15 SP7 - kernel-source In progress, kernel-default Affected). https://suse.com/security/cve/CVE-2026-98432 - checked 2026-11-01
  8. Hacker News - thread on CVE-2026-98432 (501 points as of 2026-11-01; community signal only - the community discussing and reporting MPTCP remote-root exploit research; NOT a fact source). https://news.ycombinator.com/item?id=50319143 - checked 2026-11-01