CVE-2026-98432: Linux Remote Root Risk and How to Fix It

Key Takeaways

• CVE-2026-98432 is a Linux kernel networking vulnerability. Anthropic demonstrated remote root command execution against a server with a Multipath TCP listener in a research environment.
• Patch availability depends on the distribution and kernel package. Several Ubuntu kernel packages still lacked released fixes when checked on October 30, 2026.
• A complete fix requires a vendor-confirmed patched kernel to be running, or a confirmed applicable live patch to be active.
• Disabling MPTCP is only a limited exposure-reduction measure. It is not proof that the underlying kernel vulnerability has been removed.
• Container hosts and Kubernetes nodes need attention. Updating an application image does not replace the host kernel.

Last verified: October 30, 2026. Patch tables are a dated snapshot. Recheck the linked vendor advisory before making a production change.

What Is CVE-2026-98432?

The Linux kernel security announcement describes a use-after-free involving IPv4 socket options. During TCP connection handling, option memory can be transferred to a child socket while another CPU still accesses it. Prematurely freeing that memory creates a race between readers and destruction.

The upstream correction uses kfree_rcu() so reclamation waits for an RCU grace period. This aligns memory destruction with the protection already used by readers. The affected files include net/ipv4/af_inet.c and net/ipv4/tcp_ipv4.c.

The original announcement lists fixes in 6.12.113, 6.18.56, 7.2.10, and 7.3-rc7. These are historical upstream references, not a complete distribution patch matrix or a recommendation to install a release candidate.

For Ubuntu and other distribution kernels, use the vendor's package-level advisory. Backported fixes can retain an older upstream version number, so a simple major/minor version comparison is insufficient.

What Did Claude Demonstrate?

In its October 27 security research report, Anthropic describes an unreleased internal research model producing an exploit for a Linux server with an MPTCP listener. The demonstrated attack required neither credentials nor user interaction.

The reported proof of concept took approximately 48 minutes to obtain a kernel pointer and another five minutes to achieve root command execution. These are measurements from that research setup, not a universal exploitation time.

The operational distinction matters: a demonstrated attack against a particular configuration does not establish that every exposed TCP service is exploitable, or that widespread exploitation is occurring. The publication also does not establish that a publicly available Claude Code release reproduces the same capability.

Ubuntu Patch Status: Read the Exact Package Row

The Canonical CVE tracker, last updated October 28 when retrieved, showed this snapshot:

This table does not cover every HWE, cloud, OEM, or real-time variant. It also does not make an old release a generally safe deployment choice.

Canonical displays CVSS 3.1 9.8, CVSS 4.0 8.3, and an Ubuntu priority of High. Those labels use different assessment frameworks.

A version attached to a work-in-progress entry is not evidence that the package has shipped. Wait for a released fix for the correct package and confirm that the configured repositories actually provide it.

Step 1: Identify the Running Kernel and Installed Packages

Run these commands on the actual VM or host being assessed:

cat /etc/os-release
uname -r
uname -m

Record the operating system, running kernel, and architecture. Then inspect Ubuntu's package database:

dpkg-query -l 'linux-image-*' 'linux-modules-*'

The package status matters: ii normally indicates an installed package, while rc indicates residual configuration after removal. A listing can contain multiple kernels, so match it to the kernel reported by uname -r. The dpkg-query manual explains these status columns.

Kernel suffixes such as -generic, -aws, -gcp, and -azure help identify the track, but the final decision must use the matching vendor package and revision.

Inside a container, these checks can describe different layers: /etc/os-release describes the container's userspace, while uname -r describes the shared kernel. Perform kernel remediation on the host or node that supplies it.

Step 2: Check MPTCP Exposure Without Confusing It With Patch Status

Check the current network namespace:

sysctl net.mptcp.enabled

A value of 1 permits MPTCP socket creation. It does not prove that any application is using MPTCP. Linux documents MPTCP as an opt-in protocol, although wrappers, application settings, and other mechanisms can enable it for applications. See the kernel's MPTCP documentation.

With an ss version that supports MPTCP inspection, list listeners:

sudo ss -M -lpn

The -M option selects MPTCP, -l selects listeners, and -p requests process information. Check the ss manual if the installed command rejects an option. An unsupported option is not a clean scan.

Interpret results carefully:

• Listener present: identify its service, bind address, network reachability, and business requirement.
• No listener shown: the inspected namespace has no listener visible through that check; other namespaces still need assessment.
• Sysctl missing: investigate kernel support and configuration; this does not determine whether the broader IPv4 vulnerability is patched.

The MPTCP sysctl documentation specifies that the setting is per network namespace. A host-level check does not automatically cover container namespaces.

Step 3: Check Whether Ubuntu Offers a Fix

Refresh package metadata and review available upgrades:

sudo apt update
apt list --upgradable

If an updated Ubuntu Pro Client is installed, inspect the CVE plan without applying it:

pro fix CVE-2026-98432 --dry-run

Canonical's dry-run documentation explains how this previews package changes and any required services. A dry run does not install fixes, even if its simulated summary describes a resolved state.

Optional coverage checks are:

pro status
pro security-status

Use them to understand enabled security services and maintenance coverage. They are supporting evidence, not a substitute for matching this CVE to the running kernel.

If the applicable entry still has no released fix, ordinary package updates cannot complete remediation. Keep the issue open and apply the temporary exposure controls below.

Step 4: Install the Released Ubuntu Kernel Update

Before a production update, confirm a recoverable backup or snapshot, working console access, a maintenance window, and enough capacity to move traffic away from the host.

Once the relevant vendor fix is available, use Canonical's standard update procedure:

sudo apt update
sudo apt upgrade

Review the proposed transaction before accepting it. A successful update operation only demonstrates that the offered packages were installed; the advisory still determines whether they contain this fix.

Alternatively, a configured Ubuntu Pro Client can apply the available CVE-specific remediation:

sudo pro fix CVE-2026-98432

Read its result and any subscription or service requirements. The command cannot manufacture a patch that the vendor has not released.

If the expected kernel is not offered or installed, check for holds and installation problems:

apt-mark showhold
dpkg --audit
df -h /boot /

The apt-mark documentation confirms that holds can prevent upgrades. Investigate intentional holds before changing them. Also check repository access, maintenance entitlement, and whether the machine still tracks the appropriate kernel metapackage.

Do not switch every machine to linux-generic, remove old kernels indiscriminately, or run an unreviewed full upgrade to force the issue. Cloud drivers, HWE requirements, Secure Boot, and third-party kernel modules can affect the correct upgrade path.

Step 5: Reboot and Verify That the Fix Is Active

A normal kernel package installation leaves the old kernel running until the host boots the replacement. Canonical distinguishes this from live patching in its reboot guidance.

After draining traffic and confirming the maintenance window, reboot:

sudo reboot

Reconnect and check:

uname -r
systemctl --failed

Then verify the following evidence:

1. Runtime identity: the intended patched kernel is actually running.
2. Vendor coverage: its exact package revision is listed as fixed for the applicable release and kernel track.
3. Service health: networking, storage mounts, application endpoints, and any third-party modules work correctly.
4. Persistence: the boot configuration and replacement-machine image will continue selecting a patched kernel.

If the old kernel is still running, inspect the bootloader selection and update logs before declaring success. A restart of Nginx, Docker, or an application process does not activate a replacement host kernel.

For fleet tracking, record the asset, kernel package revision, advisory, verification time, and remaining exceptions. This provides stronger evidence than an update job's exit code alone.

Can Ubuntu Livepatch Fix It Without a Reboot?

Possibly, but only if Canonical supplies an applicable patch for this CVE and the running kernel, and the client successfully applies it.

For a machine already configured for Livepatch:

pro status
sudo canonical-livepatch status

The Livepatch status documentation distinguishes kernel coverage, available patches, and application state. A healthy service or an all-applicable-patches-applied message does not independently prove that this particular CVE is included. Match the patch metadata or relevant Livepatch notice to CVE-2026-98432.

Live patches can leave uname -r unchanged. Consequently, an unchanged version does not disprove an active live fix, just as an installed newer package does not prove that it is running.

This guide does not confirm Livepatch availability for this CVE. Without explicit coverage evidence, retain the ordinary kernel upgrade and reboot plan.

Temporary Mitigation When a Patch Is Unavailable

The following measures reduce exposure while remediation remains open. They do not replace the kernel fix.

Restrict access to affected services. Prefer private networking or source allowlists where operationally possible. Preserve administrative access and test connectivity before tightening production firewall rules.

Assess whether MPTCP is required. If it is unnecessary, record the current value and test disabling new MPTCP socket creation:

sysctl net.mptcp.enabled
sudo sysctl -w net.mptcp.enabled=0

The kernel documents this control as governing socket creation. Do not assume it closes existing listeners or connections. Reconfigure or stop affected MPTCP services as appropriate, then verify listener state again. Applications that explicitly require MPTCP may fail instead of falling back to ordinary TCP.

If testing confirms that the setting is suitable, persist it through the system's configuration management. A host-level sysctl change must not be assumed to change other network namespaces. Restore the recorded value and remove any temporary override when the change is no longer required.

This is an operational inference from the documented MPTCP control, not a vendor-confirmed complete mitigation for every CVE-2026-98432 path.

Assign an owner and a review date to every unpatched system. Temporary restrictions should have a tracked exit condition: a verified active vendor fix.

Amazon Linux 2023: Use the Advisory for the Installed Kernel Branch

The Amazon Linux CVE page lists fixes for AL2023 kernel6.12 and kernel6.18, while other listed kernel packages remained pending when checked. A fix for one branch does not clear all Amazon Linux systems.

First identify the running kernel and its owning package on the host:

cat /etc/os-release
uname -r
rpm -qf "/boot/vmlinuz-$(uname -r)"

For an existing kernel6.12 installation, ALAS2023-2026-3335 lists package version 6.12.113-138.209.amzn2023 and this update path:

sudo dnf update kernel6.12 --releasever 2023.12.20261028

Review the transaction before accepting.

For an existing kernel6.18 installation, ALAS2023-2026-3251 lists package version 6.18.56-125.164.amzn2023 and this update path:

sudo dnf update kernel6.18 --releasever 2023.12.20261026

These are separate branch-specific procedures. They are not instructions to run both commands or change kernel branches.

AL2023 uses versioned repositories, so a machine locked to an older repository can miss a newer fix. The release values above reproduce the advisory snapshots, not a permanent recommendation to remain on those snapshots. If the fleet already uses a newer approved release, follow that release's current update guidance rather than selecting an older repository.

After installation, reboot during the maintenance window and verify the running kernel and owning package again. For a pending branch, track its own advisory or plan a supported migration; do not assume an available fix in another branch is already installed.

Docker, Kubernetes, and Cloud VMs

Docker's container documentation explains that containers share a kernel. For this vulnerability, rebuilding a container image does not patch the kernel that executes its network operations.

For Kubernetes, collect a node inventory:

kubectl get nodes -o wide

Use the Kubernetes node-draining workflow to plan rolling maintenance. Check spare capacity, PodDisruptionBudgets, local data, and stateful workloads before draining. Patch or replace nodes, verify their kernels and readiness, and then return them to service. Do not bypass eviction safeguards simply to accelerate the rollout.

Update node templates and machine images as part of the same change. Otherwise, autoscaling or disaster recovery can recreate the vulnerable configuration.

Common Mistakes That Leave Remediation Incomplete

A kernel patch also does not establish that a previously exposed host was never compromised. If there is credible evidence of unauthorized access, handle containment and recovery separately from patch deployment.

Conclusion

CVE-2026-98432 requires a concrete remediation decision for each kernel package and deployment. The practical endpoint is a vendor-confirmed fix active on the machine, with service health checked afterward.

Start by identifying the running kernel and MPTCP exposure. Apply the correct released update, reboot when required, and retain verification evidence. Where no fix is available, reduce exposure, assign ownership, and keep the exception open until the kernel is demonstrably remediated.