CVE-2026-80731: net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header
In the Linux kernel, the following vulnerability has been resolved:
net: remove CAPSYSRAWIO zero-padding in devvalidateheader
devvalidateheader() reads dev->hardheaderlen directly when zero-padding short link layer headers for CAPSYSRAWIO holders:
if (capable(CAPSYSRAWIO)) { memset(llheader + len, 0, dev->hardheaderlen - len); return true; }
Packet send paths call devvalidateheader() on skbs whose headroom was allocated from an earlier hardheaderlen read. If the device is reconfigured so that dev->hardheaderlen increases before validation, the memset writes past the reserved buffer, an out-of-bounds write.
This out-of-bounds write is masked in some SOCKRAW paths today because the same concurrent increase can first make skbpush() exceed the reserved headroom and trigger skbunderpanic(). Remove the zero-padding branch before making those hardheaderlen reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite.
This path is only reached for variable length L2 protocols, where len < hardheaderlen but len >= minheaderlen. No remaining in-tree variable length L2 protocol implements headerops->validate, and the CAPSYSRAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input.
Drop the CAPSYSRAWIO branch. The remaining reads of dev->hardheaderlen in devvalidateheader() are comparisons only and have no memory safety impact.
Affected Software
Event History
Frequently Asked Questions
Who could trigger the out-of-bounds write?
The path requires CAP_SYS_RAWIO and a variable-length Layer 2 protocol. The supplied link-layer header length must be shorter than hard_header_len but at least min_header_len, and the device's hard_header_len must increase after skb headroom allocation but before header validation.
How does the device reconfiguration affect exploitation?
The vulnerable memset uses the newer, increased hard_header_len, while the packet buffer headroom was reserved using an earlier value. This size mismatch can make zero-padding extend beyond the reserved buffer.
Is this path used by current in-tree variable-length Layer 2 protocols?
The description states that no remaining in-tree variable-length Layer 2 protocol implements header_ops->validate. The vulnerable path is limited to variable-length Layer 2 protocols under the stated header-length conditions.