Skip to content
HackIT
Talk to a tester

Linux kernel TCP flaw (CVE-2026-98432): how to check your servers

A Linux kernel TCP flaw the kernel team scores 9.8 (CVSS 3.1) is fixed in some Debian, Oracle, SUSE and Amazon kernels, not Ubuntu or RHEL. How to check.

HackIT Security TeamUpdated

Security alert cover for CVE-2026-98432: CVSS 3.1 score 9.8, fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3

In short: CVE-2026-98432 is a race condition in the Linux kernel's IPv4 TCP code that can make the kernel use memory it has already freed. The kernel's CVE team scores it 9.8 under CVSS 3.1 and says an attacker who is not logged in could read or corrupt kernel memory, or crash the system. Debian, Oracle Linux's UEK and some SUSE and Amazon Linux kernels are fixed, but Ubuntu and RHEL are not yet: install a fixed kernel where there is one and reboot into it.

Corrected 30 October 2026: the first version listed openSUSE Leap 16.0 as fixed, though SUSE still shows it as affected, and called Red Hat's 5.9 an earlier rating; Amazon's score (now 8.1), the RHEL products and the Go team's view are updated.

What happened

The Linux kernel's CVE team published CVE-2026-98432 on 15 October 2026. According to the CVE record, when the kernel completes a TCP handshake it hands the IP options stored with the pending connection to the new socket without copying them. If that socket is freed while another CPU is still answering a resent connection request for it, the kernel uses freed memory. IPv6 is not affected by this, because it copies the options. A similar issue affects request-socket migration, which is off by default.

The bug dates from Linux 4.4. The fix was committed on 5 October 2026 and credits Xinyang Ge of Anthropic with reporting it.

The kernel team's 9.8 assumes an unauthenticated attacker who sends connection requests carrying IPv4 options and wins the race.

On 27 October 2026, Anthropic wrote that its model, Claude, had written an exploit that lets a remote attacker with no credentials run commands as root on Linux servers with a multipath TCP (MPTCP) listener. Anthropic says the exploit leaks memory to defeat the kernel's address randomisation, then takes over its control flow, and that a lost race only fails that connection, so an attacker can keep trying. The CVE record's description and the fix do not mention MPTCP; the MPTCP exploit is Anthropic's. The Go security team, citing it, says the underlying bug is not specific to MPTCP and that systems without an MPTCP listener may be vulnerable to similar attacks.

The flaw is not in CISA's Known Exploited Vulnerabilities catalogue as of its 29 October 2026 edition.

How the vendors rate it

WhoRatingCVSS 3.1
Linux kernel CVE teamCritical9.8
Red HatImportant8.1
OracleImportant8.1
SUSEimportant8.1
AmazonImportant8.1
UbuntuHigh priorityshows 9.8

Red Hat, Oracle, SUSE and Amazon give the same score and vector: they rate the attack complexity high, where the kernel team rates it low. Red Hat says the flaw primarily results in a system crash, or potentially memory corruption.

Who is affected

Any server on Linux 4.4 or later, without the fix, that accepts IPv4 TCP connections.

MPTCP is opt-in on Linux: an application has to ask for it. Since Go 1.24, though, Go's ListenConfig uses it by default on Linux, so a Go service may listen with MPTCP without anyone choosing to.

Status on 30 October 2026:

DistributionFixed kernel
Debian 13 trixielinux 6.12.113-1 (DSA-6568-1)
Debian 12 bookwormlinux 6.1.190-1 (DLA-4841-1); linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)
Ubuntu 16.04 to 26.10None yet; work in progress for 22.04 LTS and later, and some 20.04 kernels
RHEL 8, 9 and 10, OpenShift 4 and 5None yet, no date
RHEL 7Not affected
Oracle Linux 7 to 10, UEKELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399
Amazon Linux 2023, kernel6.18kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251)
Amazon Linux 2023, kernel6.12kernel6.12-6.12.113-138.209.amzn2023 (ALAS2023-2026-3335)
Amazon Linux 2023 kernel, Amazon Linux 2Pending
SUSE: SLES 15 SP4 to SP6 LTSS, SLES 16.0, SLE Micro 5.3 to 5.5, SUSE Linux Micro 6.2Released (kernel-default)
SUSE: SLES 15 SP7, SUSE Linux Micro 6.0 and 6.1, SLES 12 SP5 LTSSNone yet

Oracle lists fixes for its UEK kernel only, not for its Red Hat Compatible Kernel. SUSE lists a fixed package for openSUSE Leap 16.0 but still shows it as affected, and the SLE Micro 5.3 real-time kernel is not yet fixed.

How to check whether you are affected

Read the running kernel and the installed kernel packages:

uname -r
dpkg -l 'linux-image*'
rpm -qa 'kernel*'

Compare the package version with your distribution's entry above, not with upstream versions. A new kernel runs only after a reboot: Amazon notes that a new kernel package needs one to take effect, and SUSE's advisory asks for one. uname -r prints the kernel release to compare.

To see whether a server has MPTCP enabled and any MPTCP listeners:

sysctl net.mptcp.enabled
ss -Ml

The kernel's default for net.mptcp.enabled is 1, enabled. In the ss manual, -M lists MPTCP sockets and -l only listening ones. A server without an MPTCP listener is not safe for that reason: the kernel team's scenario needs only a listening service.

What to do now

  1. Install the fixed kernel where your distribution has one, starting with servers that accept TCP connections from the internet, and reboot into it.
  2. If you build your own kernel, move to 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 or 7.3. The kernel team's announcement recommends the latest stable kernel and says cherry-picking individual fixes is not supported.
  3. Where no fix exists yet, as on Ubuntu and RHEL, watch the vendor's tracker and plan the reboot. Red Hat says no available mitigation meets its criteria.

Do not treat turning off MPTCP as the fix. The flaw is in the kernel's IPv4 TCP code, and neither the kernel team nor Red Hat offers it as a mitigation. The Go security team calls disabling MPTCP program by program "a fragile mitigation" and recommends a patched kernel.

What a penetration test would look for

This flaw sits in the network stack, below the application. The questions around it are which services each server exposes, and how quickly kernel updates are rebooted into. A web application penetration test looks at the application and the server it runs on, as an attacker would.

If you want to know what your servers expose to an attacker, talk to a tester.

Sources

All posts