CVE-2026-98432: patch the critical Linux kernel TCP flaw now

Status — confirmed vulnerability, no confirmed in-the-wild exploitation as at 2 November 2026.

CVE: CVE-2026-98432
Affected component: Linux kernel IPv4/TCP networking
CVSS: 9.8 Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Known exploitation: Not listed in CISA KEV as at 2 November 2026; this is not proof that exploitation is impossible.
Priority: Treat internet-facing Linux systems that accept inbound IPv4 TCP as urgent patch candidates.

What is confirmed

CVE-2026-98432 is a use-after-free flaw in the Linux kernel IPv4 networking subsystem. During a TCP connection request, IPv4 socket options can be freed while another CPU still uses them to construct a SYN-ACK. The Linux CNA record and Red Hat describe two relevant concurrent paths: a retransmitted TCP SYN during connection handling, and request-socket migration.

A remote, unauthenticated peer can reach the vulnerable TCP handshake path. No local account or user interaction is required. The confirmed outcomes are kernel memory corruption, a crash or denial of service, and potential remote code execution. Reliable code execution is timing-sensitive; do not turn that caveat into a reason to defer a patch on an exposed server.

The CVE was published on 15 October 2026 and updated on 31 October 2026. Red Hat rates the issue Critical and says fixes for affected products are being expedited.

Are you affected?

Start with systems that accept inbound IPv4 TCP: web servers, SSH bastions, reverse proxies, VPN gateways, Kubernetes or OpenShift nodes, mail relays, load balancers and appliances built on a Linux kernel. A host does not need a web application to be relevant: the vulnerable processing occurs below the application layer.

The Linux CNA record identifies Linux kernels from 4.4 onward as affected until their applicable stable fixes. Fixed stable versions currently include:

Do not compare only the first two version numbers. Distribution kernels carry backports, so the package changelog and your vendor advisory are the decision source.

Red Hat explicitly lists RHEL 8, RHEL 9, RHEL 10 and OpenShift Container Platform as directly affected; products that rely on the RHEL kernel, including RHEL CoreOS, may also be impacted.

Safe inventory and exposure check

On each authorised Linux host, record the running kernel and installed packages:

uname -r
rpm -q kernel kernel-core 2>/dev/null || dpkg-query -W -f='${Package} ${Version}
' 'linux-image*' 2>/dev/null
ss -lntp

Expected result: the first command returns the running kernel release; the second identifies the vendor package; the third lists local TCP listeners. Interpret this as an exposure inventory, not a vulnerability test. A listening service on a public interface increases urgency, but a host behind a firewall still needs patching.

For Red Hat systems, also check the vendor's advisory and package errata for the exact installed build. OpenShift teams should include node pools and RHEL CoreOS in the maintenance plan.

Patch first, then reboot into the patched kernel

Apply the kernel update using your supported vendor repository and change process. For example, on a RHEL-family host:

sudo dnf update --security kernel kernel-core kernel-modules
sudo reboot

Before rebooting, drain or fail over workload where the service requires it. The update is incomplete until the host is running the new kernel.

After maintenance, verify both the package and running kernel:

uname -r
rpm -q --changelog kernel-core | grep -i -m1 'CVE-2026-98432' || true

Expected result: the running version matches the newly installed, vendor-fixed kernel. The changelog line is supporting evidence only; vendor errata remains authoritative. If the host cannot reboot in the maintenance window, document that risk explicitly and apply the temporary mitigation below after testing it.

Temporary mitigation: filter IPv4 TCP packets with IP options

Red Hat provides an nftables mitigation that drops incoming IPv4 TCP packets carrying IP options. It reduces exposure to the affected path but is not a complete fix. Ordinary TCP options are normally carried in the TCP header, so standard traffic should continue to work; still test this in a representative non-production environment before use.

Create a narrowly scoped rule file:

cat > 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 cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Expected result: validation exits successfully and the final command shows the table and counter. Watch application health, legitimate connection failures and the counter after deployment. This rule can affect specialised networks that legitimately use IPv4 options.

After booting a fixed kernel and completing validation, remove the temporary rule:

sudo nft delete table inet cve_2026_98432

Rollback before patching is the same delete command. Do not remove the rule merely because the package has been downloaded; verify the running kernel after reboot.

Practical triage order

1. Identify internet-facing hosts and systems accepting inbound IPv4 TCP.
2. Check the running kernel and vendor package, not just the operating-system release.
3. Patch and reboot the most exposed systems first.
4. Where a prompt reboot is impossible, test and deploy the vendor nftables mitigation with an owner and expiry time.
5. Check kernel logs, service availability and unexpected reboots. A crash alone is not proof of exploitation, but it warrants incident triage and evidence preservation.
6. Review OpenShift worker and control-plane maintenance separately; node rotation and workload disruption need their own approved plan.

There is no safe reason to send crafted traffic to determine whether a host is vulnerable. Version, package provenance, configuration and exposure provide the right evidence.

What is not confirmed

As at 2 November 2026, CISA's Known Exploited Vulnerabilities catalogue does not contain CVE-2026-98432, and the available vendor/CVE records do not confirm active exploitation. That status can change. The public technical details should be enough to accelerate defensive patching, not to justify unauthorised testing.

References

1. Linux CNA CVE record for CVE-2026-98432 — publication date, CVSS vector, affected and fixed upstream versions.
2. Red Hat security bulletin RHSB-2026-016 — affected Red Hat products and supported nftables mitigation.
3. Red Hat CVE page — Red Hat severity and CVSS assessment.
4. CISA KEV catalogue — exploitation-status check, accessed 2 November 2026.
5. Linux stable fix example — upstream patch reference.

Change log

• 2 November 2026: Initial publication; verified CVE metadata, vendor advisory, affected products, fixed upstream versions and temporary mitigation.