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


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 23 Oct 2026
- **Also known as:** AZL-110765, BELL-CVE-2026-98955, DEBIAN-CVE-2026-98955, GHSA-935w-9g6m-g833, UBUNTU-CVE-2026-98955

## What is CVE-2026-98955?

CVE-2026-98955 is a vulnerability in Linux, published on 23 Oct 2026. 

### Official 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.

## Which versions are affected by CVE-2026-98955?


## How do I fix CVE-2026-98955?

Upgrade to a fixed version.

## Is CVE-2026-98955 being exploited?

There is no known exploitation of CVE-2026-98955 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-98955 and fix it if it is affected.

What it is: CVE-2026-98955 is a vulnerability in Linux, published on 23 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-98955 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-98955/ (Markdown: https://insights.sbomify.com/CVE-2026-98955/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-98955
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-98955
- OSV: https://osv.dev/vulnerability/CVE-2026-98955

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-98955/
Summaries are generated and may contain mistakes; the official description above is the record.