Cloudanix VulnDB

CVE-2026-98950

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel handles very large network packets inside certain inspection programs can cause packet details to be calculated incorrectly, risking network disruptions until the kernel is updated.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Integer truncation of hlen > U16_MAX in bpf_flow_dissect() forces nhoff and thoff to zero despite valid BPF program results because clamp_t operates on a truncated upper bound and bpf_flow_keys stores offsets as u16.

Why it matters to the business

Kernel networking stack may misclassify or drop packets on systems using custom BPF flow dissectors with large buffers, potentially causing connectivity loss or performance degradation in high-throughput network environments.

How an attack unfolds

An attacker supplies a packet that triggers a BPF flow dissector program returning offsets against an hlen exceeding 65535; the kernel truncates the bound before clamping, zeroing offsets and causing subsequent incorrect packet handling that an attacker can leverage for further misbehavior or denial of service.

How to fix it

Apply the upstream kernel patch that caps hlen to U16_MAX before the clamp operation in bpf_flow_dissect(); rebuild and deploy the fixed kernel across all affected systems.

How to confirm the fix worked

Confirm the fix is present by inspecting the bpf_flow_dissect() implementation for the U16_MAX cap before clamp_t, or test with synthetic packets where hlen exceeds 65535 and verify offsets are no longer forced to zero.

Typical attack path

  1. Deploy or coerce use of a BPF flow dissector program on the target kernel
  2. Craft or induce a packet with effective length > U16_MAX
  3. Return valid nhoff/thoff values from the BPF program
  4. Trigger truncation that zeros offsets
  5. Observe or exploit resulting incorrect flow classification

How to detect it

Review kernel logs for flow dissector warnings or unexpected zero offsets; inspect BPF program traces and packet capture metadata for hlen values exceeding 65535 accompanied by anomalous nhoff/thoff results.

What your security team should do

  • Immediately schedule kernel updates containing the referenced fix
  • Audit any custom BPF flow dissector programs for large-buffer usage
  • Monitor upstream stable kernel releases for backports
  • Temporarily disable untrusted BPF flow dissectors if patching is delayed

The record

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.

Affected packages

Ecosystem Package Introduced Fixed