CVE-2026-90160 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
lwt_bpf: Restore reserved headroom after xmit program
ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output.
That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise.
On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb.
Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability described involves a logic error within the Linux kernel's Lightweight Tunnel (LWT) BPF transmission path, specifically affecting how network buffer descriptors are validated after being modified by eXpress Data Path programs. The core issue stems from an inconsistency in headroom reservation checks during packet processing. When preparing to transmit packets via LWT XMIT mechanisms, the function ip_finish_output2 correctly expands the socket buffer to include LL_RESERVED_SPACE of the device before invoking the BPF program. This ensures sufficient space for link-layer headers. However, after the BPF program executes and potentially modifies the skb head using functions like bpf_skb_change_head, the kernel performs a recheck on remaining headroom to ensure safety before passing the packet to neighbor output routines.
The flaw lies in this post-BPF validation step where the check utilizes dst->dev->hard_header_len rather than LL_RESERVED_SPACE(dst->dev). On Ethernet interfaces, hard_header_len is typically set to 14 bytes, representing the standard MAC header size. In contrast, LL_RESERVED_SPACE accounts for alignment requirements and additional padding needed by the network stack, often resulting in a value of 16 bytes due to HH_DATA_ALIGN calculations used by neigh_hh_output. This discrepancy creates a scenario where an LWT_XMIT BPF program can reduce headroom such that exactly fifteen bytes remain after modification. The existing validation logic accepts this state because it only verifies against the fourteen-byte threshold, allowing the packet to proceed further in the processing pipeline than intended.
Once validated by the flawed check, the socket buffer is passed to neigh_hh_output for hardware header insertion. This routine relies on cached headers and strictly enforces alignment requirements using HH_DATA_MOD or HH_DATA_ALIGN logic. When it encounters a buffer with only fifteen bytes of headroom instead of the required sixteen, it triggers a headroom warning and subsequently drops the packet. This results in unintended denial of service conditions for traffic processed through LWT XMIT BPF programs that manipulate skb heads. The impact is primarily operational disruption rather than security exploitation, as the result is packet loss rather than memory corruption or privilege escalation.
To mitigate this vulnerability, developers must ensure consistency between pre-transmission reservations and post-modification validations within the kernel networking stack. The fix involves replacing the reference to hard_header_len with LL_RESERVED_SPACE(dst->dev) in the bpf_xmit headroom check. This aligns the validation logic with the initial reservation made by ip_finish_output2, ensuring that sufficient space is preserved for all alignment and header insertion requirements. From a standards perspective, this issue relates to CWE-691 which describes insufficient control of network message routing or handling, specifically regarding improper resource management in packet processing paths. It also touches upon ATT&CK technique T1498 related to Network Denial of Service via traffic manipulation, although the vector here is internal kernel logic rather than external attack vectors. System administrators should apply kernel updates that include this patch to restore proper packet forwarding behavior for LWT-based configurations and prevent unexpected drops in high-throughput or complex tunneling environments.