CVE-2026-98432: Linux Kernel TCP Remote-Root Risk

Distribution patch status

Choose a vendor-confirmed fix, not a version number from another distribution. Backported security changes can make an older-looking kernel safe from this specific flaw. Conversely, a fixed package on disk does not prove the host has booted into it. This is a dated snapshot, not a complete inventory of every kernel.

Platform names link to primary trackers. Managed hosting customers should ask for the running kernel, matching advisory and update completion time.

A patch is complete when the running host is verified

1. Record the estate. Capture each owner's distribution, support channel, kernel flavour and running version. Include gateways, container hosts and standby systems. Read-only checks such as uname -r and cat /etc/os-release help establish the baseline.
2. Confirm the fix. Record the vendor advisory and full package revision. A scanner comparing only upstream version numbers can miss backports; resolve discrepancies against vendor evidence.
3. Plan a safe rollout. Test the update, confirm backups and console access, check capacity and drain clustered nodes in turn. Define health checks and a rollback plan; rollback can restore exposure.
4. Activate the update. Install and reboot, or replace instances with a confirmed fixed image. An application restart or container rebuild does not replace the host kernel. Verify explicit CVE coverage before relying on live patching.
5. Verify the service. Compare the running kernel with the vendor-fixed package on every node. Exercise normal business traffic, check monitoring and retain evidence of the active fix.
6. Close remaining gaps. Update templates, autoscaling images and recovery nodes. For any pending fix, record compensating controls, an accountable owner and the next review date.

What goes wrong?

The kernel manages network connections before an application handles a request. A race can leave code reading memory containing IPv4 header options (not TCP options) after it has been freed: a use-after-free. This can cause memory corruption or disruption. The CNA traces the affected upstream lineage to Linux 4.4; backports and distribution builds must still be assessed through the vendor. Linux kernel CNA description and affected versions.

The advisory also describes a request-socket migration variant associated with net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. Those conditions concern the migration variant. Their absence does not rule out the separate connection-handling race.

The problem sits below website login checks and application input validation. Updating a framework alone cannot repair the host kernel. In the demonstrated root-execution scenario, potential consequences extend beyond one application to host integrity, credentials and the workloads it supports.

Which systems need attention?

Give urgent attention to reachable, affected hosts with MPTCP listeners. MPTCP allows a TCP connection to use multiple network paths. It is central to the described demonstration, but it is not the boundary of the underlying kernel bug.

The Go Security Team says Linux listening sockets use MPTCP by default from Go 1.24, subject to runtime and application configuration. Check deployed behaviour rather than assuming an ordinary-looking service uses plain TCP. Go Security Team announcement.

Our operational assessment is to prioritise internet-facing services and services reachable from untrusted networks, then address the remaining affected estate. Consider business criticality, reachable listeners, segmentation and patch availability together. An internal-only host may still be reachable by an intruder inside the network.

Containers share their host's kernel. For managed Kubernetes or hosting, establish who patches the node or host and request deployed-fix evidence. Updating only a container's user-space packages does not replace that kernel.

Read-only checks: settings and listening sockets

Run these inventory checks on the relevant host and network namespace. They query local configuration; they do not test exploitation or prove that the kernel is patched.

• Request migration: a value of 1 enables the sysctl-controlled migration path. A value of 0 does not exclude a BPF-controlled migration policy. Ask the platform owner to check whether a reuseport-migrate program is attached; unrelated BPF programs are not evidence of this condition.
• MPTCP configuration: net.mptcp.enabled=1 permits MPTCP sockets in that namespace. It does not establish that an MPTCP listener exists or that external traffic can reach it.
• Listener inventory: the ss query (short form ss -Mln) lists MPTCP listeners where the installed kernel and tools support it. Review bind addresses, routing and access controls separately. Check every relevant namespace and deployed service.
• Unknown is not safe: a failed command, missing sysctl, unsupported ss option or insufficient visibility leaves the result unknown. An empty successful listing is only a snapshot of that namespace. Neither result overrides the vendor’s affected-kernel assessment.

References: kernel TCP sysctls, MPTCP sysctls and the ss manual. These are checks, not instructions to change production settings.

Why do the severity scores differ?

The difference is not only race complexity. Assessments also differ on which confidentiality and integrity impacts are established for particular products. Keep the source, scoring version and product context beside the number.

CNA v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The 8.1 v3.1 assessments use AC:H. SUSE separately publishes CVSS v4.0 9.2, while Ubuntu publishes v4.0 8.3; compare vectors within the same version. Oracle labels its 8.1 metrics preliminary.

A lower score is not a patch exemption. Equally, a 9.8 base score does not demonstrate an identical route to root access on every affected configuration.

What has actually been demonstrated?

The primary sources reviewed do not establish in-the-wild exploitation. We downloaded the CISA KEV feed again on 30 October 2026 at 17:29 UTC. The returned catalogue was version 2026.10.29, released 29 October at 19:09 UTC, and contained no entry for this CVE. The retrieval time and feed publication time are different. Absence from KEV does not prove that attacks have not occurred; consult the current catalogue.

This evidence does not demonstrate remote-root execution against every ordinary TCP listener. However, the Go team warns that other attack paths may exist because the underlying bug is not MPTCP-specific. Go Security Team guidance.

What can you do while a patch is pending?

• Reduce reachability: remove unnecessary public listeners and restrict services that can operate with trusted-source access. Test essential business and management connections.
• Review MPTCP: the Go team documents GODEBUG=multipathtcp=0 to change a Go process's default. Explicit per-socket settings can override it. Test, restart or redeploy as appropriate, and verify the resulting listeners.
• Retain the limitation: disabling MPTCP is a fragile, partial measure. A missed listener remains exposed to that path, and the kernel defect remains. It is not a patch.
• Seek product-specific advice: do not assume a WAF, generic filtering rule or global setting completely mitigates this flaw. Red Hat lists no mitigation meeting its deployment and stability criteria.

Sources: Go Security Team; KrakenD's application-specific validation; Red Hat.

Monitoring and incident response

Do not wait for a crash. Anthropic reports that a lost race can fail the handshake without crashing the system, allowing repeated attempts. Its research run took approximately 53 minutes in total; that is one experimental result, not a dependable detection window or a time-to-compromise prediction. Research observations.

• Correlate network anomalies where telemetry exists: unusual concentrations of failed handshakes, SYN retransmissions or traffic containing IPv4 header options may warrant investigation. Retransmissions also occur during ordinary packet loss, and these are investigation leads, not validated CVE-specific signatures.
• Check telemetry coverage: flow records and application logs may omit handshake details and IPv4 header options. Confirm what existing network sensors actually record; do not assume missing records mean no attempts occurred.
• Review host evidence: correlate network findings with unexpected privileged processes, new persistence, credential use, service changes and any kernel faults. A crash alone does not identify this CVE, and no crash does not clear a host.

If compromise is suspected, preserve evidence, involve your response team and follow controlled containment and recovery. A kernel update does not establish that an already compromised host is trustworthy. Investigate possible credential exposure and rebuild from trusted sources where required.

Frequently asked questions

Primary sources and review notes

Our prioritisation and checklist are operational guidance, not a claim that ProCheckUp independently reproduced the exploit. Recheck vendor statuses before deployment decisions.