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

Check CVE-2026-98432 exposure, patch Ubuntu and Amazon Linux kernels, reduce MPTCP risk, and verify that the fix is active after reboot.

Canonical URL: https://aiidelist.com/blog/cve-2026-98432-linux-ubuntu-fix-guide

Language: en

Published: 2026-10-29

Updated: 2026-10-29

## 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](https://lists.openwall.net/linux-cve-announce/2026/10/15/1) 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](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude), 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](https://ubuntu.com/security/CVE-2026-98432), last updated October 28 when retrieved, showed this snapshot:

| Ubuntu release | Standard `linux` source package |
|---|---|
| 26.10 | Vulnerable; work in progress |
| 26.04 LTS | Vulnerable; work in progress |
| 24.04 LTS | Vulnerable; work in progress |
| 22.04 LTS | Vulnerable; work in progress |
| 20.04, 18.04, and 16.04 LTS | Vulnerable |
| 14.04 LTS | Not affected for this package |

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:

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

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

```bash
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](https://manpages.debian.org/unstable/dpkg/dpkg-query.1.en.html) 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:

```bash
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](https://docs.kernel.org/networking/mptcp.html). 

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

```bash
sudo ss -M -lpn
```

The `-M` option selects MPTCP, `-l` selects listeners, and `-p` requests process information. Check [the ss manual](https://man7.org/linux/man-pages/man8/ss.8.html) 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](https://docs.kernel.org/networking/mptcp-sysctl.html) 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:

```bash
sudo apt update
apt list --upgradable
```

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

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

Canonical's [dry-run documentation](https://ubuntu.com/pro-client/docs/en/docs/howtoguides/fix_how_to_know_what_the_fix_command_would_change/) 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:

```bash
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](https://ubuntu.com/security/cves/about):

```bash
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:

```bash
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:

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

The [apt-mark documentation](https://manpages.ubuntu.com/manpages/stonking/man8/apt-mark.8.html) 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](https://ubuntu.com/security/livepatch/docs/client/explanation/troubleshooting/do-i-need-to-reboot/). 

After draining traffic and confirming the maintenance window, reboot:

```bash
sudo reboot
```

Reconnect and check:

```bash
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:

```bash
pro status
sudo canonical-livepatch status
```

The [Livepatch status documentation](https://ubuntu.com/security/livepatch/docs/client/how-to-guides/operations/check-client-status/) 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:

```bash
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](https://docs.kernel.org/networking/mptcp-sysctl.html), **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](https://explore.alas.aws.amazon.com/CVE-2026-98432.html) 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:

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

**For an existing `kernel6.12` installation**, [ALAS2023-2026-3335](https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3335.html) lists package version `6.12.113-138.209.amzn2023` and this update path:

```bash
sudo dnf update kernel6.12 --releasever 2023.12.20261028
```

Review the transaction before accepting. 

**For an existing `kernel6.18` installation**, [ALAS2023-2026-3251](https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3251.html) lists package version `6.18.56-125.164.amzn2023` and this update path:

```bash
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](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html), 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](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/) explains that containers share a kernel. For this vulnerability, rebuilding a container image does not patch the kernel that executes its network operations. 

| Deployment | Remediation target |
|---|---|
| Ubuntu VM on AWS, Google Cloud, or Azure | The guest operating system's actual kernel package |
| Docker on a Linux host | The host kernel |
| Self-managed Kubernetes | Each affected node's kernel or replacement node image |
| Managed Kubernetes | The provider-supported node update mechanism and applicable node image |
| Fully managed application hosting | The provider's applicable security notice and service responsibility model |

For Kubernetes, collect a node inventory:

```bash
kubectl get nodes -o wide
```

Use the [Kubernetes node-draining workflow](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) 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

| Mistake | Why it fails | Better evidence |
|---|---|---|
| Running only `apt update` | It refreshes metadata without installing a kernel | Installed package and advisory match |
| Treating work in progress as fixed | Preparation is not package availability | Released vendor fix available to the host |
| Installing a fixed kernel without booting it | The old kernel can remain active | Running kernel match or verified live patch |
| Treating MPTCP disabled as CVE resolved | Configuration reduction does not remove vulnerable code | Vendor-confirmed active fix |
| Updating only Docker images | The shared host kernel remains unchanged | Host or node remediation |
| Trusting a version-only scanner | Distribution backports can be misclassified | Distribution-aware package assessment |

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.