CVE-2026-80731
massLinux kernel out-of-bounds write in dev_validate_header (CAP_SYS_RAWIO path)
CVE-2026-80731 is an out-of-bounds write in the Linux kernel's dev_validate_header() networking helper, where a CAP_SYS_RAWIO branch zero-pads short link-layer headers using dev->hard_header_len even though the skb headroom was sized from an earlier read of that same value. It is triggered when a local process holding CAP_SYS_RAWIO sends packets over raw (SOCK_RAW) sockets with short, variable-length L2 headers while the device is concurrently reconfigured so hard_header_len increases, causing the memset to write past the reserved buffer; in some paths this race surfaces first as a loud skb_under_panic rather than a silent overwrite. Successful triggering corrupts adjacent kernel memory, and the CVSS 7.8 (AV:L/PR:L, high C/I/A) score implies potential local privilege escalation or a system crash, though no exploit is currently known. Any Linux kernel carrying the vulnerable code is affected in principle, but the maintainers note the path is reached only for variable-length L2 protocols, that no remaining in-tree variable-length L2 protocol implements a validate op, and that the CAP_SYS_RAWIO bypass exists mainly for testing malformed input, so the realistically reachable set is narrow. There is no public PoC, the flaw is not in CISA KEV, and EPSS estimates only ~0.2% probability of exploitation within 30 days (8th percentile); the fix removes the CAP_SYS_RAWIO zero-padding branch entirely.
What to do: Track your distribution's security advisory for CVE-2026-80731 and install the kernel update containing the patch that removes the CAP_SYS_RAWIO zero-padding branch in dev_validate_header (specific fixed version numbers are not stated in this disclosure). As an interim mitigation, grant CAP_SYS_RAWIO only to trusted processes and avoid sending short, variable-length L2 headers over raw packet sockets while interfaces are being reconfigured. Given the local attack vector, no public PoC, and EPSS of ~0.2%, patching via normal maintenance cycles is reasonable.
| Linux kernel (net: dev_validate_header) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len 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 = min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.