CVE-2026-98432 was published on 15 October 2026 by the Linux kernel's own numbering authority and last updated on 3 November. It carries one CVSS score, 9.8 CRITICAL, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

The National Vulnerability Database has no score of its own. Nineteen days after publication its record for this CVE is still marked Received, which means nobody at NVD has analysed it.

So the only assessment of a 9.8 in the TCP stack comes from the people who wrote the patch. That is unusual, and what they did with it is more unusual still.

The flaw

The title is the commit subject: ipv4, free inet_opt and ireq_opt after an RCU grace period.

When a TCP connection completes, the kernel hands the IP options stored against the request socket to the new child socket without copying them. Another CPU can be using those same options at that moment, building a SYNACK in response to a retransmitted SYN. Child sockets are not freed under RCU, and the destructor releases the options with a plain kfree. The result is a use-after-free in ip_options_build.

A second path does the same thing through request socket migration, where a cloned request socket and the original share one options structure and the destructor frees it the same way. The fix is to use kfree_rcu in both places.

IPv6 escapes the first half, because its equivalent duplicates the options. The kernel says the migration half does exist for IPv6 and will be addressed in a separate patch, so there is a second fix still to come.

What the kernel did that almost nobody does

Most numbering authorities publish a score. The Linux CNA published a paragraph of reasoning for each of the eight metrics. We have not seen another vendor do this on a kernel CVE, and it is worth reading because it answers in advance the objections that usually get raised.

On AV:N, how a remote attacker reaches it: an unauthenticated peer supplies IPv4 Record Route or Timestamp bytes in a TCP SYN, the kernel stores them, and the peer's retransmitted SYN then races the frees. No account, no session, no application involvement.

On AC:L, which is the metric people argue about whenever a race condition is scored high, its own sentence: "Both racing sides are attacker-induced; multicore scheduling and heap grooming do not constitute conditions outside the attacker's influence."

On PR:N: the vulnerable code runs during the handshake, before any application authentication, and the target performs no check on the peer's valid IP options.

On C:H: after the options are freed, the SYNACK builder copies from the stale structure into the packet, so reclaimed heap contents go out to the attacker. On I:H: stale offsets steer a memcpy, giving out-of-bounds kernel writes. On A:H: a reclaimed length can make the kernel push past the packet headroom and panic.

Read together, that is an argument, not a number. Whether you accept it or not, you can check it.

The age

The record says the bug arrives with commit 079096f103fa, "tcp/dccp: install syn_recv requests into ehash table", and the affected range starts at Linux 4.4. That kernel was released in January 2016.

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.

The ingredient almost nobody uses

The trigger needs IPv4 Record Route or Timestamp options in the SYN. These are from the original IP specification and are close to extinct in normal traffic. Plenty of networks drop packets carrying IP options at the edge, which is a real mitigation, and plenty of networks do not.

It also means that an alert on inbound SYNs carrying IP options is a cheap and specific detection, because almost nothing legitimate on the public internet sends them.

Nobody has reported an attack

We checked the Known Exploited Vulnerabilities catalogue directly. CVE-2026-98432 is not in it. No vendor, no CERT and not the kernel CVE team has reported exploitation.

That is worth stating plainly next to the 9.8, because the two facts will be quoted separately. A critical score describes what a flaw would do. It says nothing about whether anyone has done it.

What to do

  • Patch. The fixed versions are listed above and cover every supported stable line.
  • Until you have, drop inbound packets carrying IPv4 options at the perimeter if your traffic does not need them. Most does not.
  • Add the same thing as a detection even after patching. A SYN with Record Route set is a strong, low-volume signal.
  • If you run request socket migration, with tcp_migrate_req enabled or a reuseport migration program, note that it is the second affected path rather than an unrelated one.
  • Watch for the IPv6 follow-up the record promises.
  • Do not wait for NVD to agree. The record has been sitting unanalysed for nineteen days and the patches exist now.

What is not established

  • Whether anyone has exploited it. No such claim exists anywhere we could find.
  • Whether remote code execution is achievable in practice. The kernel argues the mechanism; nobody has demonstrated it.
  • Why NVD has not analysed the record.
  • How many systems are reachable with IP options permitted. No survey exists.
  • When the IPv6 patch arrives, or what it will be numbered.