Most kernel CVEs need a local foothold. CVE-2026-98432 doesn’t. It lives in the code that accepts inbound IPv4 TCP connections, so any Linux host with a listening TCP port is in scope. Red Hat rates it Critical, the Linux kernel CNA scores it CVSS 9.8, and over the weekend vendors started shipping fixes at very different speeds.
What actually breaks
The upstream fix, announced on the linux-cve-announce list on October 15 as “ipv4: free inet_opt and ireq_opt after an RCU grace period”, describes two races.
- The SYN-ACK race. When
tcp_v4_syn_recv_sock()turns a request socket into a full child socket, it hands over the request’s IPv4 options (ireq_opt) to the child without copying them. Another CPU can be processing a retransmitted SYN for the same request at the same time and building a SYN-ACK that reads those options. Request sockets haven’t been processed under the listener lock since the old commit “tcp/dccp: install syn_recv requests into ehash table”, and the child freesinet_optwith a plainkfree(). If the child goes away first,ip_options_build()reads freed memory. - The migration race. With
net.ipv4.tcp_migrate_req=1or aBPF_SK_REUSEPORT_SELECT_OR_MIGRATEprogram, a cloned request socket shares the same options as the original. The clone’s destructor can free them while another CPU still uses the old request.
The fix switches both destructors to kfree_rcu(), which matches what other paths that replace inet_opt already do. IPv6 isn’t affected by the first race because it copies the options.
How bad is it in practice?
The vendors agree it’s serious, but they emphasize different things:
- Red Hat (RHSB-2026-016): a remote, unauthenticated attacker could trigger the race to get remote code execution. “Exploitation requires precise timing of network requests but does not require any privileges or user interaction.” Systems that accept inbound TCP connections are the most exposed.
- AWS (bulletin 2026-160-AWS): crafted IPv4 TCP packets carrying IP options can cause a crash, a kernel memory leak, or memory corruption, and researchers have demonstrated unauthenticated RCE against hosts with an MPTCP listener. AWS says it isn’t aware of exploitation in the wild.
- CISA KEV: not listed as of the October 30 catalog, according to Oflight’s November 1 digest.
The bug has been there since kernel 4.4, so it’s present on nearly every server, VM and container host in service today.
Patch status (as of November 1–2)
| Platform | Status |
|---|---|
| Upstream stable | Fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 |
| Debian | Fixed (bookworm 6.1.190-1, trixie 6.12.113-1) |
| Amazon Linux 2 / 2023 | Fixed kernels available. AL2023 hosts locked to a release need 2023.12.20261102 or later |
| Amazon EKS / ECS | EKS-optimized AL2023 AMIs v20261031 and ECS-optimized AMI 20261031. Fargate tasks launched after Nov 1, 17:00 UTC use a patched platform |
| RHEL 8, 9, 10 / OpenShift | Affected, no fixed kernel yet. Red Hat says it is expediting fixes |
| Ubuntu 22.04, 24.04, 26.04 | Listed as vulnerable, fixes in progress |
AWS also says managed L7 front doors (ALB, CloudFront, API Gateway, WAF) don’t pass untrusted TCP straight to your instances. Network Load Balancer TCP listeners, Global Accelerator, PrivateLink and VPC Lattice L4 targets do pass IP options through, so the Linux targets behind them need patching or the interim rule.
Interim mitigations
Red Hat publishes an nftables table that drops inbound IPv4 TCP packets with IP options. Ordinary traffic carries its TCP options in the TCP header, so most workloads shouldn’t notice, but test it first:
# cve-2026-98432.nft (from Red Hat RHSB-2026-016)
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
# after the kernel is patched:
sudo nft delete table inet cve_2026_98432
AWS adds two options: an equivalent iptables u32 rule, and turning off MPTCP with net.mptcp.enabled=0 (or GODEBUG=multipathtcp=0 for applications built with Go 1.24 or later). Both vendors say these steps only reduce exposure. A fixed kernel and a reboot are the only complete fix.
What to do today
- Inventory internet-facing Linux hosts and anything sitting behind L4 load balancers. Run
uname -rand compare it with your distribution’s fixed version. - On Debian and Amazon Linux, update the kernel and reboot. Installing the package alone doesn’t change the running kernel.
- On RHEL and Ubuntu, stage the nftables rule in non-production, roll it out to exposed hosts, and schedule the reboot window for when fixed kernels land.
- Check whether any of your services opt in to MPTCP. If they don’t need it, disable it.
- Refresh node images for Kubernetes clusters (EKS AMI v20261031 or later) rather than patching nodes in place.
For more patch-priority advisories, see our security tracker.