CVE-2026-98432: Linux IPv4 TCP Use-After-Free - Ubuntu LTS Still Open

CVE-2026-98432 is the Linux kernel CNA’s name for a use-after-free in IPv4 TCP connection setup. Upstream title: ipv4: free inet_opt and ireq_opt after an RCU grace period. NVD id CVE-2026-98432. vulnStatus Awaiting Analysis. published 2026-10-15T13:17:13.987. lastModified 2026-11-06T19:28:12.867. Source identifier is the kernel CNA (416baaa9-dc9f-4396-8d5f-8c081fb06d67). NVD lists no CWE. Red Hat records CWE-825 (expired pointer dereference) and Bugzilla 2553390.[1][2][3]

Kernel CNA CVSS 3.1 is 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) as a Secondary metric. NVD has no Primary score. Red Hat’s own product score is the same vector, severity Critical, public_date 2026-10-15. It is not on CISA KEV. Catalog 2026.11.06, 1,769 entries.[1][2][4]

The reason this is still the floor this morning: Ubuntu 24.04 / 22.04 / 20.04 remain Vulnerable, work in progress on Ubuntu’s CVE page. Ubuntu 26.10 is Fixed in 7.3.0-10.10. RHEL 8/9/10 errata landed 1 November. Debian bookworm/trixie security already have fixed kernels. Proxmox published PSA-2026-00080-1 with proxmox-kernel-7.0.14-25-pve. If you run Ubuntu LTS hosts, you still do not have a USN-shaped reboot target.[5][6][7][8]

What it is

This is a kernel IPv4 TCP handshake bug, not a web-app RCE and not PHP2Shell.[1]

The kernel commit text, paraphrased only as far as NVD reprints it: tcp_v4_syn_recv_sock() transfers ireq->ireq_opt to the child socket without copying. Another CPU can handle a retransmitted SYN for the same request socket and build a SYN-ACK from tcp_check_req(), reading those options under rcu_read_lock() only. Child TCP sockets do not have SOCK_RCU_FREE. inet_sock_destruct() frees inet_opt with a plain kfree(), which is a use-after-free in ip_options_build(). A second race exists when request sockets migrate (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program): clone and original share ireq_opt, then the old pointer is cleared. Fix: kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(). Debian’s tracker points at linus commit e3f33b0a1d89d738e2b913dab519226eaf76e15b (7.3-rc7).[1][7]

Upstream is explicit about scope we will not widen:

Native IPv6 is not affected by the first race (tcp_v6_syn_recv_sock() duplicates options). A CALIPSO/ipv6_opt migration issue is called out as a separate patch.
Proxmox’s PSA restates: only SYNs carrying IPv4 options, or CIPSO/NetLabel setups, hit the affected code.[1][8]

Red Hat’s bulletin: a remote unauthenticated attacker could exploit the race during TCP connection-request processing to trigger remote code execution. Input is IPv4 options on an inbound connection request, plus one of those races (retransmit or socket migration). Exploitation requires precise timing. Disabling MPTCP is not a complete mitigation. Default RHEL already has MPTCP off and is still vulnerable.[9]

Anthropic’s public write-up (linked from Red Hat’s bulletin) demonstrated an RCE path on a server with MPTCP listeners. Go 1.24 enables MPTCP by default for listen sockets on Linux; the Go security team told oss-security on 29 October that disabling MPTCP in Go is a fragile mitigation and the kernel patch is the fix. That is Go’s statement about their default, not a claim that every listener is MPTCP.[9][10]

We did not send crafted SYNs. Treat “RCE” as vendor-rated potential (kernel CNA 9.8 + Red Hat Critical), not as a public, reliable exploit we reproduced.

How serious is it?

On paper: unauthenticated, network, no user interaction, high C/I/A. That is why Red Hat moved it to Critical and why CloudLinux customers keep asking whether KernelCare has the ID.[2][9][11]

In practice, vendors disagree on how easy the race is:

Red Hat: reliably executing code through this timing-sensitive UAF requires precise heap control; they still rate Critical because of crash / memory corruption on ordinary inbound TCP.[2]
CloudLinux (article dated 2 November 2026): kernel developers could not trigger it remotely on EL kernels; no public exploit; no in-the-wild report; not KEV. They also note Oracle/SUSE had scored 8.1 while kernel CNA / Ubuntu / Red Hat sat at 9.8 as of that day.[11]
CISA has not added it. Newest KEV row this morning is SonicWall SSLVPN CVE-2026-19868 (6 Nov), then WordPress core CVE-2026-119977 (3 Nov) - already covered here on 31 Oct as the 7.1.4 upgrade-window bug.[4]

Do not flatten those into “it’s fine until KEV.” Also do not flatten them into “zero-click root on every public SSH port.” The published trigger still needs IPv4 options (or CIPSO/NetLabel) and a race.

Who is affected

In scope until you hit a vendor floor, kernels 4.4 and newer (CloudLinux: the bug was introduced in 4.4). Any host that accepts inbound IPv4 TCP is the published surface. That is every public web/mail/SSH box, not “only MPTCP.”[9][11]

Floors we actually pulled this morning:

Distro / product	Status this morning	Floor / errata
RHEL 8	Fixed 1 Nov	`kernel-4.18.0-553.182.1.el8_10` - RHSA-2026:93414 (rt: RHSA-2026:93415)
RHEL 9	Fixed 1 Nov	`kernel-5.14.0-687.64.1.el9_8` - RHSA-2026:93412
RHEL 10	Fixed 1 Nov	`kernel-6.12.0-211.72.1.el10_2` - RHSA-2026:93413
RHEL 6 / 7	Not affected	Red Hat `package_state`
Debian bookworm (security)	Fixed	`linux` 6.1.190-1
Debian trixie (security)	Fixed	tracker 6.12.115-2; DSA-6568-1 names 6.12.113-1
Ubuntu 26.10	Fixed	`linux` 7.3.0-10.10
Ubuntu 24.04 / 22.04 / 20.04 / 18.04	Vulnerable, work in progress	no USN on the CVE page
Ubuntu 14.04	Not affected	Ubuntu tracker
Proxmox VE	PSA-2026-00080-1 31 Oct	`proxmox-kernel-7.0.14-25-pve` (and `-signed`)
CloudLinux OS 7 (3.10)	Not affected	CloudLinux, 2 Nov
CloudLinux OS 8 / 9 / 10	Affected; KernelCare live patch 8/9 released as of 2 Nov	see CloudLinux article - live patch ≠ reboot kernel

AlmaLinux / Rocky follow the RHEL NVR once it is in their repos. Do not assume the RHEL NVR is already on the mirror you actually use.

OpenShift: bulletin says OCP 4 is affected (RHCOS). OCP 4.22 CoreOS is Fixed in RHSA-2026:95346 (6 Nov). OCP 4 CoreOS 8 and OCP 5 CoreOS 9 still show Affected on Red Hat’s CVE JSON this morning. RHEL AI 3 kernel: Affected.[2][9]

What to do now

Read the running kernel, not the package that last downloaded.

uname -r
# EL:
rpm -q kernel
# Debian/Ubuntu:
dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}'
# Proxmox:
pveversion -v | grep -E 'proxmox-kernel|pve-kernel'

Compare to the floor for your train. 4.18.0-553.177 is still below 553.182.1 on RHEL 8.

Patch and reboot where a fixed kernel exists.

# RHEL 8/9/10 / Alma / Rocky
sudo dnf update kernel
sudo reboot
uname -r

# Debian bookworm/trixie (security)
sudo apt update
sudo apt install --only-upgrade linux-image-amd64
sudo reboot

# Proxmox
apt update
apt install --only-upgrade 'proxmox-kernel-7.0.14-25-pve*'
# confirm the new kernel is in the boot list, then reboot

A dnf update that leaves you on the old uname -r is not a patch.

Ubuntu LTS: do not invent a USN. Ubuntu’s CVE page this morning still says work in progress for 24.04 (6.8.0-149.149), 22.04 (5.15.0-203.213), 20.04. Packages in -proposed are opt-in testing, not a production floor. Until Ubuntu flips those rows to Fixed, the stopgap is Red Hat’s nftables drop of IPv4 TCP packets with IP options - RH says it reduces exposure and cannot fully prevent it. Test it. It is not persistent across reboot unless you save it.[5][9]

# Red Hat RHSB-2026-016 - not persistent
cat >/tmp/cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
EOF
sudo nft --check --file /tmp/cve-2026-98432.nft
sudo nft --file /tmp/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Remove after the fixed kernel is running: sudo nft delete table inet cve_2026_98432. Ubuntu publishes a similar ip hdrlength > 5 table. Ordinary TCP options (timestamps, window scale) live in the TCP header; this rule targets IPv4 options. If you actually need IPv4 options or CIPSO, this rule will break that traffic - RH says so.[5][9]

CloudLinux / KernelCare: grep the CVE, do not trust “No updates are needed.” CloudLinux, 2 Nov: kcarectl --update can say nothing is needed while kcarectl --patch-info | grep CVE-2026-98432 is empty. Empty means not patched. CL8/9 live patch was released that day (not on ePortal yet). CL10 was test feed only. Rebooting into a testing kernel can drop KernelCare coverage until that NVR is in the production kernel list. Follow their article, not this paragraph, for the current prefix.[11]

kcarectl --patch-info | grep CVE-2026-98432
sysctl net.mptcp.enabled   # expect 0 on default CL 8/9/10

Do not use net.mptcp.enabled=0 as the fix. RH: MPTCP off is the RHEL default and the box is still affected. CloudLinux: keep MPTCP disabled until the live patch or fixed kernel is in, because the known remote exploit chain needed it - the bug itself is still in ordinary TCP. Go binaries on 1.24+ can open MPTCP listeners even when you think the sysctl is enough; restart those processes after the sysctl if you go that route, and still patch the kernel.[9][10][11]
After the new kernel is running, look for the published impact classes - crash / memory corruption - not a CVE-specific IoC (none was published). Kernel oops around TCP handshake, unexpected reboots, tainted kernel. We are not publishing exploit steps.

Versions with no floor

Ubuntu 24.04 / 22.04 / 20.04 this morning: no Fixed row. nftables is a reduction, not a close.
EOL Ubuntu 16.04 / 18.04: tracker still says vulnerable / ignored. Upgrade the OS.
RHEL 6 / 7: Not affected for this ID. Still EOL. That is not permission to keep them on the internet.
Custom / panel / appliance kernels with no errata: isolate or replace.
OpenShift 4 nodes not yet on RHSA-2026:95346: RH says apply the nftables MachineConfig from their OCP solution; pod-to-pod is not covered. Kernel update is the complete fix.[9]

Compromise signs

None of these prove CVE-2026-98432. Together they are enough to snapshot and rotate.

uname -r below the floor and the host accepts public IPv4 TCP.
Kernel oops / panic during handshake storms you cannot explain.
New root SSH keys, new SUID binaries, unexpected kernel modules - general host compromise, not a published IoC for this ID.

CISA did not list this CVE. There is no BOD due date.

FAQ

Is this on CISA KEV? No. Catalog 2026.11.06 (1,769). The WordPress KEV this week is CVE-2026-119977, already shipped here as the 7.1.4 upgrade-window post.[4]

Is it unauth RCE? Kernel CNA and Red Hat score it that way (9.8 / Critical). Red Hat’s statement still says reliable code exec needs precise heap control. CloudLinux says EL kernel developers could not trigger it remotely. We are reporting both, not picking a winner.[1][2][11]

Does disabling MPTCP save me? No, not as a complete mitigation. RH is explicit. It may remove one demonstrated chain (Anthropic / MPTCP listeners; Go 1.24 default).[9][10]

Does ss -Mlnp showing no MPTCP listeners mean I am safe? Red Hat: no. Informational only.[9]

IPv6-only host? Upstream: native IPv6 is not affected by the first race. Dual-stack boxes still have IPv4 TCP. Do not skip the patch because “the site is v6.”[1][8]

Is livepatch enough? Only if kcarectl --patch-info (or the Ubuntu livepatch CVE list) names this ID. A livepatched host on a vulnerable base is still vulnerable until the CVE is in the livepatch set.[11]

Honesty

We did not exploit this. No SYN-with-IP-options PoC was run.
CVSS 9.8 is kernel CNA Secondary and Red Hat product. NVD is Awaiting Analysis with no Primary score.[1][2]
Not KEV. No public IoCs. CloudLinux’s “no wild use” sentence is dated 2 November, not this morning.
Ubuntu LTS status is from the CVE tracker fetch 8 November 2026. -proposed is not a floor.
CloudLinux KernelCare / ePortal / test-feed sentences are from that 2 Nov article. Recheck before you reboot a KC host into a testing kernel.
CWE: NVD none; Red Hat CWE-825. We do not invent CWE-416.
Anthropic’s MPTCP demo is a vendor-linked research write-up, not a CISA exploitation record.

Sources

NVD CVE-2026-98432 - Awaiting Analysis; kernel CNA 9.8 Secondary AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; published 2026-10-15T13:17:13.987; lastModified 2026-11-06T19:28:12.867
Red Hat CVE-2026-98432 - Critical; CWE-825; RHSA-2026:93412 / 93413 / 93414 (RHEL 9/10/8); hydra JSON pulled 2026-11-08
CVE Record / kernel stable commits listed on NVD
CISA KEV JSON - catalogVersion 2026.11.06, count 1769; CVE-2026-98432 absent
Ubuntu CVE-2026-98432 - 26.10 fixed 7.3.0-10.10; 24.04/22.04/20.04 Vulnerable work in progress (fetched 2026-11-08)
RHSA-2026:93413 - RHEL 10 kernel-6.12.0-211.72.1.el10_2, 1 Nov 2026
Debian tracker CVE-2026-98432 - bookworm security 6.1.190-1; trixie security 6.12.115-2; DSA-6568-1 / DLA-4841-1
Proxmox PSA-2026-00080-1 - 2026-10-31, proxmox-kernel-7.0.14-25-pve(-signed)
RHSB-2026-016 - nftables ip hdrlength > 5; MPTCP-off is not a complete mitigation
oss-security, 29 Oct 2026 - Go 1.24 MPTCP default; kernel patch is the fix
CloudLinux, 2 Nov 2026 - CL7 not affected; CL8/9 KernelCare released; grep --patch-info; no public exploit as of that article