johnhsb/linux-tcp-uaf-cve-2026-98432CVE-2026-98432 (Linux IPv4 TCP inet_opt UAF): read-only diagnostic script, no-reboot nftables/sysctl mitigations, Ansible rollout and response guide (EN/KO)
A response kit for CVE-2026-98432, a memory-safety bug in the code the Linux kernel uses to set up TCP connections. It contains three things:
iptables, or nftables where iptables is missing), kernel-setting (sysctl) files and Ansible playbooks, all applied without a reboot. The default mode only counts packets.Written as of 2026-11-03. Every mitigation here is temporary and does not replace the kernel fix. Schedule the kernel update and reboot (or a livepatch) separately.
| README | Guide | Diagnostic script | |
|---|---|---|---|
| πΊπΈ English (default) | README.md | cve-2026-98432-guide.en.md | check_cve_2026_98432.sh |
| π°π· νκ΅μ΄ | README.ko.md | cve-2026-98432-guide.ko.md | check_cve_2026_98432_ko.sh |
iptables and needs no reboot. To be safe, it starts by counting only; switch to dropping once you've confirmed no legitimate traffic is affected.The IP header of a TCP connection request can β rarely β carry extra fields called IPv4 options. The kernel keeps those options in memory while the connection is being set up. When it cleaned up, it freed that memory immediately, even though another CPU core could still be reading it.
Using memory after it has been freed is called a use-after-free (UAF). If something else has been placed there in the meantime, the kernel reads the wrong data, which can lead to:
| Item | Detail |
|---|---|
| Affected | Linux 4.4 and later, before each branch's fixed version. IPv6 is not affected |
| Severity | CVSS 9.8 (Critical) from the Kernel CNA, Red Hat and Ubuntu. SUSE, Amazon and Oracle rate it 8.1, because winning the timing race between CPUs is hard |
| Root cause | Memory was freed without waiting for the kernel's safe-free period (RCU grace period). Upstream fix: commit e3f33b0a1d89 (kfree β kfree_rcu) |
| Fixed kernel versions | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 or later β for distribution kernels, check whether the fix is included, not the version number |
Exploitation: as of 2026-11-03 it is not in CISA KEV (the catalog of vulnerabilities known to be exploited), and no real-world attacks have been reported. Many GitHub repositories claim to be "PoCs"; none are verified β do not run them on production networks.
Fixed kernels by distribution (versions and sources in guide Β§2.2)
| Distribution | Status |
|---|---|
| RHEL 8 / 9 / 10 | β Fixed kernels released 2026-11-01 (RHSA-2026:93414 / 93412 / 93413). OpenShift (RHCOS) nodes are not fixed yet |
| Debian 12 / 13 | β Fixed (DSA-6568-1, DLA-4841-1, DLA-4850-1) |
| Amazon Linux 2 / 2023 | β Fixed. EKS/ECS-optimized AMIs, Fargate and Bottlerocket are rolling out |
| Rocky Linux (CIQ RLC Pro / LTS) | β Every CIQ-supported variant fixed. For community Rocky, check Rocky Errata |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | β³ In progress ("work in progress" as of 2026-11-03) |
| Ubuntu 16.04 / 18.04 / 20.04 | β³ Standard support has ended β fixes expected for Ubuntu Pro (ESM) subscribers only |
| SUSE, Oracle Linux, AlmaLinux, β¦ | Fixes reported β check each vendor's own advisory |
The diagnostic script in 4. What to do now gives you the exact verdict. As a rough guide:
For an attack to work, β the server needs at least two CPU cores (two cores must touch the same memory at the same moment), and β‘ the attacker's packet must reach the server with its IPv4 options intact.
| # | If the server is⦠| Risk | What to do |
|---|---|---|---|
| 1 | In an internal VPC or a Kubernetes node, multi-core, with an MPTCP listener (including in containers) | π΄ Remote root | Apply the firewall rule and sysctl now, and patch node kernels. Some Kubernetes networks (eBPF-based CNIs) bypass the host firewall, so patching comes first |
| 2 | On a public IP or behind an L4 load balancer (AWS NLB, β¦) with an MPTCP listener | π΄ Remote root | Apply the firewall rule and sysctl now |
| 3 | Multi-core with only ordinary TCP services | π Remote crash | Apply the firewall rule (sysctl alone does not help) |
| 4 | Single CPU (one vCPU) | π‘ Very unlikely to succeed | Include in the regular patch cycle |
| 5 | Reachable only through an L7 proxy (AWS ALB, CloudFront, Cloudflare, β¦) with controlled internal access | π‘ Attack packets never arrive | Patch to defend against internal attackers |
β οΈ Don't conclude "no MPTCP listener, so we're safe." Red Hat says checking for MPTCP listeners is "informational rather than reassurance." Without MPTCP a crash is still possible, and another exploitation method that doesn't need MPTCP can't be ruled out. Also, on RHEL 8-family kernels
ss -Mmay show MPTCP listeners as plain TCP.
π‘ L4 vs. L7: an L7 proxy ends the client's TCP connection and opens a new one to your server, so the attacker's IPv4 options never reach it. An L4 load balancer (AWS NLB TCP listeners, Global Accelerator, PrivateLink, VPC Lattice, β¦) passes packets through unchanged, which is the same as exposing the server directly.
A read-only script that checks patch status, mitigations and exposure (including containers) and tells you the risk level.
sudo bash check_cve_2026_98432.sh
To see the reasoning behind the verdict:
sudo bash check_cve_2026_98432.sh --verbose