CVE-2026-98432 Linux TCP flaw: 9.8 per kernel CNA, 8.1 on Red Hat's page, and no Ubuntu or RHEL fix listed

One Linux kernel flaw, four different base scores, and two big vendors with no fix listed

CVE-2026-98432, a race in how the Linux kernel handles the IPv4 TCP handshake, carries four different CVSS 3.1 base scores in the pages read on 29 October 2026: 9.8, 8.1, 7.0 and 5.9 (derived count of distinct values). The Linux kernel CNA, the body that assigned the CVE, scores it 9.8 Critical. Red Hat, SUSE and Oracle print 8.1, Amazon prints 7.0, and Red Hat's security data feed prints 5.9. The CVE was published on 15 October 2026, so on 29 October it is 14 days old (derived). In that time Debian and Oracle listed fixed kernels after one day, SUSE and Amazon after 9 to 14 days for some releases, and Ubuntu and Red Hat, whose names lead the headline that prompted this read, list no fixed package at all.

This briefing reads the primary records, not the coverage. The Hacker News headline, as a search listing showed it, says the flaw has a 9.8 score and affects Ubuntu, Red Hat and other distributions. That page sits behind a challenge and was not read, and nothing here depends on it. The CVE.org record, the NVD record, the pages of Ubuntu, Red Hat, SUSE, Debian, Oracle and Amazon, the CISA catalogue and Anthropic's post were each read between 18:22 and 18:40 GMT on Thursday 29 October 2026.

What the score gap does not establish: it does not say whether anyone is attacking. Red Hat's page flags no known exploit and the CISA Known Exploited Vulnerabilities catalogue, version 2026.10.28, does not list the CVE. It also does not say that every Linux server is open to remote root. The 9.8 and the 8.1 describe the same bug. They differ on one input, how hard the race is to win (derived below), and that one input moves the number by 1.7 points.

What the bug is, in the CVE record's own words

The CVE text, assigned by the Linux kernel CNA, is titled "ipv4: free inet_opt and ireq_opt after an RCU grace period". It reproduces what reads like the fix's commit message. The commit itself on git.kernel.org was not read, because that host's robots.txt disallows automated fetching, so the CVE text is the primary used here. In plain words: when a TCP connection is being set up over IPv4, the kernel stores any IP options from the first packet with the pending request. When the handshake finishes, the new connection takes over those options without copying them. If the other side retransmits its first packet, another processor can still be building a reply from those options at the moment the connection is torn down and the options are freed. The reply then reads freed memory. That is a use after free.

Zoom

Three facts from the record decide who is exposed. First, the CVE text says IPv6 is not affected by the first issue, because the IPv6 code duplicates the options. Second, there is a second, similar path through request socket migration, which the text ties to the setting net.ipv4.tcp_migrate_req=1 or to a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. The kernel documentation read for this briefing gives that setting a default of 0, disabled. Third, the text says the IPv6 migration case, which only arises with CALIPSO, "will be addressed in a separate patch". So a fixed kernel for this CVE may not be the end of the family.

The record lists the flaw as present from kernel 4.4 and 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. Most servers do not run an upstream kernel. They run a distribution kernel, which numbers its packages differently and backports fixes, so the vendor's own status is what counts. That is the next section but one.

Who scored what, and why the number moves

NVD lists the record as "Received", meaning it has not yet analysed it, and the only score on it is the kernel CNA's, shown as a secondary source. So the headline 9.8 is the CNA's own number, not NVD's. Each distribution then scores the flaw for its own kernels, as Red Hat's page explains.

Zoom

The arithmetic can be checked. Using the CVSS 3.1 formula (derived), the CNA's vector gives an exploitability subscore of 3.89 and an impact subscore of 5.87, a base score of 9.8. Change only attack complexity from Low to High and the exploitability subscore falls to 2.22, the impact stays at 5.87, and the base score is 8.1. Amazon's lower impact values give 7.0, and Red Hat's feed, with a crash as the only impact, gives 5.9. All four figures reproduce from the vectors each source printed.

The disagreement is about a judgement, not a measurement. The CNA's scoring text says attack complexity is Low because "Both racing sides are attacker-induced", so a determined peer can keep trying. Red Hat's feed, read at the same time as its web page, says the High rating "reflects the high attack complexity of winning the race" and that no confidentiality or integrity impact has been demonstrated, with a denial of service the "practical worst case". Anthropic's post, covered below, claims a working exploit, and that is a claim about the same judgement from a different direction.

Red Hat's own two surfaces disagree with each other. Its customer portal page, whose record shows a change at 12:08 GMT on 29 October, prints Important, 8.1, and lists RHEL 8, 9 and 10 as Affected. Its security data feed, fetched at 18:24 GMT, prints Moderate, 5.9 and lists the same products as Fix deferred. The records do not say which is newer. A scanner that reads the feed and a person who reads the page will therefore see different severities for the same Red Hat kernel.

The patch state per vendor, 29 October 2026

The headline names Ubuntu and Red Hat because they are the two that have not shipped. The others have, for some or all of their kernels. The table gives each vendor's status as printed, the fixed package or advisory, and the date the vendor gives.

Zoom

Two readings of the same table matter to a defender. For Debian, Oracle and SUSE customers the work is to install and reboot. For Ubuntu and Red Hat customers it is to wait for a vendor kernel with no date given, and to decide what to do about internet facing hosts in the meantime. Ubuntu prints the kernel version in which it is working on the fix, for example 6.8.0-149.149 for 24.04 LTS and 5.15.0-203.213 for 22.04 LTS. That is a work item, not a package a customer can install. Red Hat's FAQ on the page says a Fix deferred status "means that a fix for an affected product version is not guaranteed due to higher-priority development work".

Vendors sell support and subscriptions for these kernels, so each has an interest in how its own score and its own status read. Red Hat's page says its scores reflect how a vulnerability affects its products specifically, which is a fair statement and also a commercial one.

Exploitation: a vendor's claim, a catalogue that does not list it, and a record that does not say multipath

Three things can be checked. The CISA Known Exploited Vulnerabilities catalogue, version 2026.10.28, released at 19:00 GMT on 28 October 2026 and holding 1,762 entries, does not contain CVE-2026-98432 (read again at the end of this build). Red Hat's page carries a field for a known exploit and it is false. No vendor page read states that the flaw is being exploited.

Anthropic's research post, dated 27 October 2026, is the source of the exploitation story. It links this CVE and says that after initial prompting its model wrote an exploit that lets a remote attacker send packets to Linux servers "with a multipath TCP listener" and run commands as root, without credentials. In its proof of concept, it says, the attacker took 48 minutes to leak a kernel pointer and five more minutes to reach a shell command, 53 minutes in all (derived). The post adds that a lost race only fails the handshake, so an attacker can retry. This site read the same post in the briefing on its five attack chains. Anthropic sells the model and an access programme for it, which is its interest in saying how capable the model is.

The CVE text, the Ubuntu, Red Hat, SUSE and Debian pages and the Amazon and Oracle pages never use the words multipath or MPTCP (checked by search of each saved page). The record describes ordinary IPv4 TCP. So either multipath TCP is one route to the same code that the record leaves unmentioned, or the post and the record do not match exactly. The records cannot choose. If it is the first reading, any IPv4 TCP listener on an affected kernel is in scope, not only multipath ones. No exploit is published or linked by any source read, and none is described here.

What the 9.8 vector means, and what it hides

A CVSS vector is a list of assumptions, and each letter is a claim. Reading the CNA's vector against its own scoring text:

So the headline 9.8 hides two conditions that a reader should hold on to. One is the exposure condition: a reachable listening IPv4 TCP service. The other is the judgement about the race: a crash is the effect nobody disputes, and the rest rests on how reliably the race can be won. A base score also says nothing about whether your kernel is the affected build. A distribution kernel that backports the fix carries an older version number and may be safe, and one that does not may carry a number that looks new.

The friendly name problem is sharper here than in most stories. "Critical" and "9.8" read as a verdict, and "Moderate" and "5.9" read as relief. Neither is a control. "Work in progress" is not a package, "Fix deferred" is not a fix date, "Pending Fix" is not a patch, and Red Hat's "Affected" tells a customer nothing about when. A patch is a kernel version running on a machine after a reboot.

Technical details

The artifacts below are what the vendors and CVE.org print, copied from the saved pages, each captioned with its source and the date read. No vendor prints a detection command, a firewall rule or an indicator of compromise, and no source read publishes exploit code. The only configuration names in the primary records are the two sysctl settings quoted from the kernel documentation. The three commands at the end are this site's own, derived from the setting names, and are not vendor guidance.

The CVE.org record: the CNA's vector, the introducing commit, the affected and unaffected version lines, and the eight fix commits, as printed.

CVE-2026-98432
assigner: Linux   state: PUBLISHED
dateReserved: 2026-09-25T10:25:14.348Z
datePublished: 2026-10-15T12:08:22.205Z
dateUpdated: 2026-10-24T14:08:46.326Z
title: ipv4: free inet_opt and ireq_opt after an RCU grace period
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   baseScore: 9.8   baseSeverity: CRITICAL
programFiles: net/ipv4/af_inet.c, net/ipv4/tcp_ipv4.c
affected (introducing commit): 079096f103faca2dd87342cca6f23d4b34da8871
affected from: 4.4
unaffected from: 5.10.272 (5.10.*), 5.15.223 (5.15.*), 6.1.190 (6.1.*), 6.6.159 (6.6.*),
                 6.12.113 (6.12.*), 6.18.56 (6.18.*), 7.2.10 (7.2.*), 7.3 (original_commit_for_fix)
fix commits (lessThan):
  b3b027ef0cd322bfa839b9aaf5b27551eea54cf6
  95a8c8fa9f27dce64c40c41c062de7728bf34ab5
  89b5b1eb7d633c33832b7ff2c02e19a144705036
  742f73df544e03744f2981c467d6542fe8172a2a
  11a03ce3c4a62d84c10ccdfe47f8075006498568
  a47406c769f72c070386985488f1c4d057df86b2
  26d4c36d318cffbbd160884a0e4cec0da4da4936
  e3f33b0a1d89d738e2b913dab519226eaf76e15b

The CVE text, which is what reads like the fix's commit message. It is the primary for the mechanism.

In the Linux kernel, the following vulnerability has been resolved:

ipv4: free inet_opt and ireq_opt after an RCU grace period

tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
child socket (newinet->inet_opt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same
request socket, and send a SYNACK from tcp_check_req().
tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
under rcu_read_lock() only, and ip_build_and_send_pkt() and
ip_options_build() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a
reference on its request socket, and inet_csk_reqsk_queue_drop()
calls timer_delete_sync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install syn_recv requests
into ehash table"), request sockets are processed without holding
the listener lock, so nothing prevents the child socket from being
freed while the SYNACK is still being built. TCP child sockets do
not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt
with a plain kfree(), leading to a use-after-free in
ip_options_build().

A similar issue exists with request socket migration
(net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE
program). reqsk_timer_handler() clones the request socket with
inet_reqsk_clone(), so that the old request socket and its clone
share the same ireq_opt, then reqsk_migrate_reset() clears the
pointer in the old one. Another cpu holding a reference on the old
request socket can still be using these options (sending a SYNACK,
or creating a child in tcp_v4_syn_recv_sock()) when the clone is
freed, and tcp_v4_reqsk_destructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inet_opt
(do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use
kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and
tcp_v4_reqsk_destructor() as well.

IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()
duplicates the options. tcp_v6_reqsk_destructor() has the same
migration issue with ipv6_opt, which is only set by CALIPSO. This
will be addressed in a separate patch.

Ubuntu's status table for the main linux package. The version is where Ubuntu says it is working on the fix. No Ubuntu Security Notice was linked.

26.10 stonking | Vulnerable | work in progress in 7.3.0-10.10
26.04 LTS resolute | Vulnerable | work in progress in 7.0.0-43.43
24.04 LTS noble | Vulnerable | work in progress in 6.8.0-149.149
22.04 LTS jammy | Vulnerable | work in progress in 5.15.0-203.213
20.04 LTS focal | Vulnerable
18.04 LTS bionic | Vulnerable
16.04 LTS xenial | Vulnerable
14.04 LTS trusty | Not affected

Red Hat's two surfaces, side by side. They print different severities and different states for the same products.

Red Hat web page, CVSS v3 score breakdown (preliminary and subject to review)
Red Hat:  8.1   CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
cve.org:  9.8   CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
NVD:      N/A
Severity: IMPORTANT
Package state: RHEL 6 kernel Not affected; RHEL 7 kernel, kernel-rt Not affected;
RHEL 8 kernel, kernel-rt Affected; RHEL 9 kernel, kernel-rt Affected; RHEL 10 kernel Affected;
OpenShift Container Platform 4 openshift/ose-rhel-coreos-8 and ose-rhel-coreos-9 Affected

Red Hat Security Data API
threat_severity: Moderate
cvss3_base_score: 5.9
cvss3_scoring_vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
status: draft
cwe: CWE-825
package_state: RHEL 6 kernel Out of support scope; RHEL 7 kernel, kernel-rt Not affected;
RHEL 8 kernel, kernel-rt Fix deferred; RHEL 9 kernel, kernel-rt Fix deferred; RHEL 10 kernel Fix deferred;
OpenShift Container Platform 4 openshift/ose-rhel-coreos-8 and ose-rhel-coreos-9 Fix deferred
mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.

SUSE's fixed package versions and advisories. SUSE's page lists many more products and package names; four are shown.

SUSE Linux Enterprise Server 16.0:                 kernel-default >= 6.12.0-160000.40.1
SUSE Linux Enterprise Server 15 SP6-LTSS:          kernel-default >= 6.4.0-150600.23.143.1
SUSE Linux Enterprise Server 15 SP5-LTSS:          kernel-default >= 5.14.21-150500.55.195.1
SUSE Linux Enterprise Server 15 SP4-LTSS:          kernel-default >= 5.14.21-150400.24.246.1
SUSE Linux Enterprise Server 15 SP7:               kernel-default  Affected
SUSE Security Advisories: SUSE-SU-2026:24386-1, SUSE-SU-2026:24422-1, published Thu Oct 29 13:04:53 CET 2026
Overall state of this security issue: Pending

Debian's tracker table, with the advisory references.

linux (source)
bookworm            6.1.176-1       vulnerable
bookworm (security) 6.1.190-1       fixed
trixie              6.12.107-1      vulnerable
trixie (security)   6.12.113-1      fixed
forky               7.2.12-1        fixed
sid                 7.2.13-1        fixed
linux-6.12 (source)
bookworm (security) 6.12.113-1~deb12u1  fixed
References: DLA-4841-1, DLA-4850-1, DSA-6568-1

Amazon Linux and Oracle Linux.

Amazon Linux 2         Core, Kernel-5.10 Extra, Kernel-5.15 Extra, Kernel-5.4 Extra   kernel   Pending Fix
Amazon Linux 2023      kernel                                  Pending Fix
Amazon Linux 2023      kernel6.12   2026-10-29   ALAS2023-2026-3335   Fixed
Amazon Linux 2023      kernel6.18   2026-10-24   ALAS2023-2026-3251   Fixed
Amazon Linux CVSSv3    7.0   CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H

Oracle Linux version 10 (kernel-uek)   ELSA-2026-500399   2026-10-16
Oracle Linux version 9 (kernel-uek)    ELSA-2026-500398, ELSA-2026-500399   2026-10-16
Oracle Linux version 8 (kernel-uek)    ELSA-2026-500397, ELSA-2026-500398   2026-10-16
Oracle Linux version 7 (kernel-uek)    ELSA-2026-500397   2026-10-16
CVSS v3: 8.1   CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

The two settings the sources name. The first is the second path named in the CVE text. The second is the multipath switch Anthropic's post refers to. The kernel documentation does not call either a mitigation for this CVE, and no vendor says that disabling multipath removes the risk.

tcp_migrate_req - BOOLEAN
The incoming connection is tied to a specific listening socket when
the initial SYN packet is received during the three-way handshake.
When a listener is closed, in-flight request sockets during the
handshake and established sockets in the accept queue are aborted.
If the listener has SO_REUSEPORT enabled, other listeners on the
same port should have been able to accept such connections. This
option makes it possible to migrate such child sockets to another
listener after close() or shutdown().
Possible values:
0 (disabled)
1 (enabled)
Default: 0 (disabled)

/proc/sys/net/mptcp variable
enabled - BOOLEAN
Control whether MPTCP sockets can be created.
MPTCP sockets can be created if the value is 1. This is a
per-namespace sysctl.
Default: 1 (enabled)

Derived by this site, not printed by any vendor: three read only commands that show the running kernel and the two settings. Compare the first against your vendor's fixed package, not against the upstream version numbers.

uname -r
sysctl net.ipv4.tcp_migrate_req
cat /proc/sys/net/mptcp/enabled

What to do, in the order worth doing

Nothing below needs a model, an exploit or a verdict on the score. The order puts what a fixed package can solve first, then the hosts that have to wait.

What could not be verified

• The Hacker News page. Behind a challenge, not read. The headline is known only from a search listing.
• The fix commit and the kernel mailing list. The robots.txt of git.kernel.org and lore.kernel.org disallows automated fetching, so neither was read. The CVE text is used instead.
• Which Red Hat surface is newer. The portal page and the data feed disagree and no timestamp settles it.
• Anthropic's exploit. Nothing independent confirms it, no code is published, and the post's description does not match the record's wording on multipath.
• Exposure counts. No source gives a number of vulnerable hosts.
• Ubuntu fix dates. None is given. The status for livepatch and ESM was not separately read.
• Vendor pages are automatic. Oracle says its page has not been checked for errors, and the SUSE page warns its state may be work in progress or outdated.

The question that exposes the gap

When your scanner shows a 9.8 on an Ubuntu or RHEL host that accepts IPv4 TCP from outside today, who decides whether the 9.8 or the 8.1 sets the deadline, and can that person say on what date the vendor kernel will be installed and running?

Key facts