CVE-2026-90160: lwt_bpf: Restore reserved headroom after xmit program
In the Linux kernel, the following vulnerability has been resolved:
lwtbpf: Restore reserved headroom after xmit program
ipfinishoutput2() expands an skb to LLRESERVEDSPACE(dev) before LWT xmit. An LWTXMIT BPF program can then modify the skb head and still return BPFOK, so bpfxmit() rechecks the remaining headroom before the skb continues to neighbour output.
That recheck uses dst->dev->hardheaderlen. This is not enough for the neighbour cached-header path: neighhhoutput() copies the cached hardware header using the aligned hhcache size, HHDATAMOD for short headers or HHDATAALIGN(hhlen) otherwise.
On Ethernet, hardheaderlen is 14 but the cached copy needs 16 bytes. If an LWTXMIT BPF program calls bpfskbchangehead(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neighhhoutput() hits its headroom warning and drops the skb.
Use LLRESERVEDSPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.
Affected Software
Event History
Frequently Asked Questions
What configurations are exposed to this issue?
Systems using LWT_XMIT BPF programs are exposed when such a program modifies skb headroom and returns BPF_OK. The failure is specifically reachable on the neighbour cached-header output path; Ethernet is an example because its 14-byte hardware header requires 16 bytes in the aligned cached-header copy.
What does an attacker or triggering workload need to do?
The triggering LWT_XMIT BPF program must reduce packet headroom while allowing transmission to continue. The described example calls bpf_skb_change_head(skb, 1, 0), leaving 15 bytes of headroom, which passes the prior check but is insufficient for the cached Ethernet header copy.
What is the observable impact?
The neighbour cached-header output path emits a headroom warning and drops the packet. This results in packet transmission failure for the affected traffic path.
What change resolves the problem?
The post-BPF headroom check must use LL_RESERVED_SPACE(dst->dev) rather than dst->dev->hard_header_len. This matches the headroom reservation performed before LWT transmission and accounts for cached-header alignment requirements.