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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1 - Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1117.124~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1123.132~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1122.131~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1118.128~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-198.208~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1112.118~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-195.205~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-198.208 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1122.131 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1113.119 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1100.108 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1112.118 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1109.114 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-195.205 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1112.113 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-xilinx-zynqmpto a version that resolves this vulnerability.Fixed in 5.15.0-1080.84 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1101.103 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1109.111 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1116.125 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-198.208+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128+fips1 - Configuration
Remove the CAP_SYS_RAWIO branch that zero-pads and accepts short link-layer headers; remove the zero-padding before validation.
Linux kernel dev_validate_header() CAP_SYS_RAWIO zero-padding branch = disabled
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.