CVE-2026-98432: check your Linux servers and patch the running kernel

What is CVE-2026-98432?

CVE-2026-98432 is a use-after-free bug in the Linux kernel’s IPv4 TCP handshake path. Concurrent connection processing can read socket-option memory after it has been freed. A remote attacker needs access to an affected TCP listener; authentication is not required. Kernel crashes and potential code execution make this an urgent patching task. Red Hat’s CVE assessment describes the impact.

The timing race makes exploitation more demanding, but it does not make an exposed server a reasonable place to wait. Ubuntu lists a CVSS v3.1 score of 9.8. Use your vendor’s affected-package status to make the patching decision. Check Ubuntu’s severity and kernel status.

Which servers should you check first?

Start with hosts that accept IPv4 TCP connections from untrusted networks. Include public application endpoints, directly reachable origins, SSH access, and exposed database ports. Then inspect private paths that tenants, partners or compromised workloads could reach. A private IP changes reachability; it does not establish patch status.

Containers share their host’s kernel. Rebuilding an application container will not patch the node underneath it. For a cluster, record the running kernel on each node and roll through replacements with capacity and disruption budgets in view.

For AWS deployments, check bulletin 2026-160 before choosing an action. AWS assigns self-managed EC2 kernel updates to customers and provides separate guidance for EKS, ECS, Fargate and load-balancing services. Its guidance distinguishes TCP pass-through listeners from services that terminate client connections. A load-balancer name alone is insufficient evidence of protection.

How does the TCP memory race happen?

The TCP handshake establishes a connection through SYN, SYN-ACK and ACK packets. This bug concerns rarely used IPv4 header options, such as Record Route or Timestamp. These differ from TCP options such as MSS and window scaling.

1. A SYN arrives with IPv4 options. The kernel stores those options in memory.
2. The accepted connection’s new socket takes ownership of that memory without copying it.
3. A retransmitted SYN can make another CPU prepare a SYN-ACK using the same options.
4. The new socket can close and free the memory before that CPU finishes reading it.

The fix defers freeing the options until readers have finished, using kfree_rcu() in place of immediate freeing. The Debian tracker reproduces the kernel description and links the upstream fix, commit e3f33b0a1d89. Distribution kernels may receive that fix through a backport.

What fixes it, and what only reduces exposure?

Red Hat documents temporary IPv4-options filtering. Review the rule for your host firewall, forwarding paths and orchestration layer before applying it. Test legitimate traffic and prepare a rollback. Dropping all TCP options would be a different change with much broader consequences.

AWS also recognizes livepatching as a remediation option. The useful evidence is an active patch for this specific CVE on the running kernel. An installed livepatch agent or a generic “up to date” message does not establish that coverage. See AWS’s remediation guidance.

A patching checklist for production teams

1. Inventory and assign an owner. Record OS release, running kernel, package flavor, listeners, reachability and service owner for each host or node.
2. Match the vendor advisory. Compare the complete distribution package build with its fixed version. Upstream version numbers alone can miss backported fixes. If the evidence is incomplete, record “unknown.”
3. Contain while preparing the change. Restrict unnecessary access. Use vendor-recommended IPv4-options filtering where appropriate, with traffic validation and a rollback plan.
4. Roll out the fix. Patch and reboot standalone hosts in a maintenance window. For clusters, check spare capacity, drain and replace nodes in controlled batches, and update the image used for future nodes.
5. Verify before closing the ticket. Confirm the running kernel or active livepatch, service health, error rates and replacement images. Retain the advisory URL, evidence and verification time.

Use these read-only commands to start collecting evidence on a Linux host. Access to process details may require additional privileges.

cat /etc/os-release
uname -r
ss -lntp
sysctl net.mptcp.enabled

uname -r identifies the running kernel; it does not prove a fix is present. A missing MPTCP sysctl does not prove safety either. Consult the package manager and vendor advisory for your distribution, and distinguish the installed kernel from the one actually booted.

Why does MPTCP appear in the advisories?

The Go security team’s advisory says Anthropic demonstrated code execution against an MPTCP listener. It also states that the underlying bug is not specific to MPTCP and recommends a patched kernel. That distinction matters when deciding whether an ordinary TCP service needs attention.

Go 1.24 changed the default for Linux listening sockets to enable MPTCP. Compatibility settings and explicit socket configuration can affect behavior, so inspect the actual application. GODEBUG=multipathtcp=0 changes a default; explicit per-socket settings can override it. Go documents the default and compatibility controls.

What is Multipath TCP useful for?

Multipath TCP lets a connection use multiple network paths, such as Wi-Fi and mobile data, with ordinary TCP subflows underneath. RFC 8684 defines the protocol. It can support continuity across paths and use available capacity on multiple links.

Linux’s net.mptcp.enabled setting allows creation of MPTCP sockets and is enabled by default per network namespace. Applications still need to request those sockets. See the kernel’s MPTCP sysctl documentation.

For a server with one stable connection, the immediate benefit can be limited. The MPTCP project FAQ explains the server trade-offs and fallback to regular TCP. Decide whether to use MPTCP based on networking needs. Keep the CVE remediation decision tied to kernel patch status.

Copy this prompt to assess your server

Give this to an assistant with authorized, read-only access to your host, or use it to guide a manual review. It asks for evidence and separates patch status from network exposure. A prompt cannot determine vulnerability without current vendor guidance and access to the relevant host information.

Download as .txt

Assess this Linux server for CVE-2026-98432 using a read-only investigation. Work only on systems I own or am authorized to assess. Do not send exploit packets, run a proof of concept, install software, change firewall/sysctl settings, patch, drain nodes or reboot.

1. Identify whether you are on the host, in a container, or in a VM. Collect /etc/os-release, uname -r, architecture, installed kernel package versions and boot time. If containerized, explain that the shared host kernel must be assessed and request host-level evidence.
2. Consult current official distribution/provider advisories for CVE-2026-98432. Cite exact URLs and retrieval dates. Match the running kernel to the correct distribution release, package flavor and vendor fixed build. Account for backported fixes. Do not classify by upstream version alone. If no matching advisory or evidence is available, report UNKNOWN and explain what is missing.
3. Distinguish installed patched kernels from the currently running kernel. Check reboot status using available distribution tools. If livepatch is used, verify explicit coverage for this CVE and that the patch is active on this kernel; the presence of a livepatch agent is insufficient.
4. Inventory IPv4 TCP listeners with ss -lntp (or an available equivalent). Explain wildcard and dual-stack listeners. Inspect available host firewall rules read-only. Ask for cloud security groups, NACLs, load-balancer listener/target configuration, public routes and any direct-origin access that local evidence cannot establish. Separate kernel patch status from network reachability. Treat internal untrusted paths as relevant too.
5. For Kubernetes/ECS, assess node or container-instance kernels, current node image/AMI and replacement templates; a rebuilt container image does not update the shared host kernel. Identify which infrastructure is provider-managed and which is customer-managed.
6. Record MPTCP settings and relevant Go listener configuration as context only. net.mptcp.enabled=0, absent MPTCP support or GODEBUG=multipathtcp=0 do not prove the underlying TCP vulnerability is fixed. IPv4 options differ from TCP options.

Return a concise evidence table with: host/node, OS and kernel package, running kernel, vendor advisory and fixed build, active livepatch evidence, IPv4 listener/reachability evidence, patch status (PATCHED / VULNERABLE / UNKNOWN), exposure (REACHABLE / RESTRICTED / UNKNOWN), recommended action, owner and validation step. Report inaccessible evidence explicitly. Never label a host safe because it has no public IP or because a scan found no open port.

Finish with a prioritized remediation plan for review: vendor-supported patched kernel plus controlled reboot/node replacement, or a supported active livepatch covering this CVE; temporary vendor-recommended IPv4-options filtering and access restrictions where needed. Include availability checks, rollback planning and post-change verification. Propose commands separately; execute no changes without my approval. Do not read or print credentials, environment secrets, private keys or unrelated application data.

Common questions

Does disabling MPTCP fix CVE-2026-98432?

No. The underlying bug is in ordinary IPv4 TCP handling. Disabling MPTCP can reduce the demonstrated exploit’s conditions, but remediation still requires the kernel fix. The Go security team explains the limitation.

Is IPv6 affected?

The kernel description says the IPv6 path copies the options and avoids this particular ownership bug. A dual-stack service may still accept IPv4 connections. Verify its actual listeners and network paths. Read the kernel description in Debian’s tracker.

Is installing a kernel update enough?

A newly installed kernel normally takes effect after reboot. Verify that the booted kernel matches the fixed vendor build, or confirm an applicable livepatch is active. AWS details the remediation requirement.

This guide summarizes public vendor advisories. CloudHero has not claimed to reproduce the exploit or assess your environment. Recheck the linked advisories before making changes.