Skip to main content
VulnerabilityPublished

CVE-2026-98955: Linux kernel · flow_dissector: avoid u16 truncation of skb->len when computing thoff

Source GCVE Database

0
Authoritative record:CVE-2026-98955

Not known to be exploited · fixed in d9e08836d06c84abb18470c94b12b131eaccdc7d : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity
Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS
0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in d9e08836d06c84abb18470c94b12b131eaccdc7d, 9993e6a0ac1b5b3101ffba702cacb9f42b9909d8, 99bda1ecbd56905f8bd934b9cdccd3bd251192b1 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • >=4.4.114 <4.5
  • >=4.9.79 <4.10
  • >=4.14.16 <4.15
Fixed in
  • d9e08836d06c84abb18470c94b12b131eaccdc7d
  • 9993e6a0ac1b5b3101ffba702cacb9f42b9909d8
  • 99bda1ecbd56905f8bd934b9cdccd3bd251192b1
  • 52efce4755a4b8b82039caa773645ffc80b25362
  • 50d0cd575cab763f833d6ac6eb6550b23a0b3dae
  • 4.15
  • 4.10
  • 4.5
LinuxLinuxAffected
  • =4.15
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transport header inside the Ethernet header. Such skbs are not exotic: - At the time of commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tun_get_user() dissect IFF_TAP frames before eth_type_trans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549]. Compare as u32 instead. If the resulting offset cannot be represented in the u16 key_control->thoff, cap it to U16_MAX and report the dissection as failed rather than silently returning a wrong transport offset. thoff is still set on failure, as some callers (such as eth_get_headlen()) use it regardless of the return value.

References

Community reviews

Loading reviews…