CVE-2026-98950 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's network stack relies on a flow dissector mechanism to parse packet headers and extract key fields such as network header offset and transport header offset for efficient processing in various subsystems including networking, security modules, and eBPF programs. A critical vulnerability exists within the bpf_flow_dissect function where improper handling of length values leads to integer truncation issues that can result in incorrect flow key extraction or denial of service conditions. The core issue stems from how the kernel sanitizes offsets returned by BPF programs using a clamp operation with u16 type constraints on header lengths exceeding standard limits.
When processing packets through eBPF-based flow dissectors, the function bpf_flow_dissect receives a header length value hlen that represents the total size of headers to be parsed within the packet buffer. The implementation uses clamp_t macro to constrain returned offsets nhoff and thoff between zero and this hlen value using u16 type casting for the upper bound comparison. This creates a dangerous truncation scenario when hlen exceeds sixty-five thousand five hundred thirty-five, which is the maximum value representable by an unsigned sixteen-bit integer. In such cases where hlen equals exactly sixty-five thousand five hundred三十六 or higher, the upper bound gets truncated to sixty-five thousand five hundred thirty-five before comparison occurs against potentially larger valid offset values returned by BPF programs.
This truncation causes both nhoff and thoff fields within struct bpf_flow_keys to be forced to zero regardless of whether the BPF program actually computed sane, correct offsets for network and transport header positions. The consequence is that subsequent code relying on these flow keys will operate with incorrect positional data about where headers begin within packet buffers. This misalignment can lead to parsing errors when accessing header fields at calculated addresses derived from truncated offset values, potentially causing kernel panics through invalid memory accesses or allowing malformed packets to bypass security checks designed around proper header boundary detection.
The vulnerability represents a classic integer overflow class issue categorized under CWE-190 Integer Overflow or Wraparound in the Common Weakness Enumeration database. From an ATT&CK perspective this relates to techniques involving exploitation of software vulnerabilities for denial of service impacts rather than direct privilege escalation since the primary impact involves disrupting network processing capabilities within kernel space. The bug specifically affects scenarios where large packets with extended header options trigger hlen values beyond standard ethernet frame limits, making it particularly relevant in environments handling jumbo frames or complex encapsulation schemes like VXLAN GRE or MPLS tunnels.
This issue mirrors a previously fixed vulnerability documented in commit ninety-nine bda one ec bd five six regarding skb length truncation during transport header offset computation but remained unaddressed for the BPF code path because __skb_flow_dissect returns early when custom BPF flow dissectors handle packet processing instead of using default kernel dissector logic. The structural difference between these two code paths meant that while general network stack protections were updated, eBPF-specific handling retained its vulnerable truncation behavior creating an inconsistent security posture across different packet processing mechanisms within the same subsystem.
The root cause lies in struct bpf_flow_keys storing nhoff and thoff as u16 values which inherently limits their maximum representable value to sixty-five thousand five hundred thirty-five bytes. When hlen exceeds this threshold without proper validation before clamping operations, the comparison logic fails to enforce correct bounds checking resulting in forced zero assignments for both offset fields. This design flaw assumes header lengths will never exceed standard frame sizes but modern networking scenarios frequently involve larger packets requiring extended parsing capabilities that expose these limitations within existing constraint mechanisms.
Mitigation strategies require immediate patching of affected kernel versions through official distribution updates provided by Linux maintainers and vendors who incorporate this fix into stable release branches. Administrators should verify their current kernel version against known vulnerable ranges and apply corresponding security patches promptly to restore proper header parsing functionality for eBPF-based network processing pipelines. Organizations deploying advanced networking features involving large packet sizes or complex encapsulation protocols must ensure their infrastructure runs patched kernels to prevent potential denial of service conditions arising from truncated offset calculations during high-volume traffic scenarios.
Long-term architectural improvements should include adding explicit validation checks that reject hlen values exceeding reasonable maximums before any clamping operations occur rather than relying solely on type-based constraints within comparison functions. Implementing comprehensive fuzz testing specifically targeting edge cases involving large header lengths and complex packet structures would help identify similar truncation vulnerabilities across other network processing paths. Additionally documenting these limitations in developer guidelines for eBPF program writers could prevent future occurrences by encouraging explicit bounds checking before passing values into kernel flow dissector interfaces that expect standard-sized parameters within defined operational ranges.