UBUNTU-CVE-2026-80731: High severity ubuntu/linux vulnerability
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
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 short link-layer headers using dev->hard_header_len.
Linux kernel dev_validate_header() CAP_SYS_RAWIO zero-padding branch = disabled
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
An attacker needs local access and CAP_SYS_RAWIO. The affected path also requires a variable-length Layer 2 protocol and a race in which the device's hard_header_len increases between skb allocation and header validation.
Are ordinary network configurations likely to be affected?
The vulnerable path is limited to variable-length Layer 2 protocols where the supplied header length is below hard_header_len but at least min_header_len. The data states that no remaining in-tree variable-length Layer 2 protocol implements header_ops->validate, which limits practical exposure.
What behavior might indicate the issue is being triggered?
Some SOCK_RAW paths may produce skb_under_panic when the concurrent hard_header_len increase causes skb_push() to exceed reserved headroom. Without that masking behavior, the condition can result in an out-of-bounds write during zero-padding.