---
id: "CVE-2026-98950"
kind: "vulnerability"
aliases: ["CVE-2026-98950"]
title: "Linux kernel: BPF flow dissector truncates header length, misreads packet offsets"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["bpf", "linux-kernel", "networking", "runtime"]
not_affected_if: ["no-bpf-flow-dissector"]
published_at: "2026-10-23T13:17:16+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98950", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98950", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: BPF flow dissector truncates header length, misreads packet offsets

In the Linux kernel's BPF flow dissector, the header-length bound is truncated to 16 bits before clamping, so packets longer than 65535 bytes get their offsets forced to zero. The sources do not describe an attacker-controlled outcome beyond incorrect packet dissection.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare the running kernel to the fixed upstream kernel release listed in the NVD entry
- Check whether BPF flow dissector programs are loaded with `bpftool prog show` (unknown whether this affects your setup)

## Fix

- Update the Linux kernel to a release that includes the upstream commit that caps hlen to U16_MAX (exact fixed version: unknown)

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98950
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98950

## From the sources

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

flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

bpf_flow_dissect() sanitizes the offsets returned by the BPF program
with clamp_t(u16, ..., hlen).

If hlen is bigger than 65535, the upper bound is truncated before
the comparison. For instance, with hlen == 65536, both nhoff and
thoff are forced to zero, even if the program returned sane values.

This is the same class of bug as the one fixed in commit 99bda1ecbd56
("flow_dissector: avoid u16 truncation of skb->len when computing
thoff"). That fix does not cover the BPF path, because
__skb_flow_dissect() returns early when a BPF flow dissector
handles the packet.

struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen
to U16_MAX before clamping.

Found by sashiko while reviewing the commit above.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_