CVE-2026-80731 net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header
A race condition in the Linux kernel allows out-of-bounds writes via CAP_SYS_RAWIO, potentially enabling code execution or privilege escalation.
- Exploited in the wild
- Not known
- Login needed
- Any signed-in user
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-80731?
CVE-2026-80731 is a high-severity memory corruption vulnerability in Linux, published on 3 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
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 < hard_header_len but 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.
Which versions are affected by CVE-2026-80731?
How do I fix CVE-2026-80731?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-80731 being exploited?
There is no known exploitation of CVE-2026-80731 in the wild and no public exploit code.
Sources
Also known as AZL-99054, BELL-CVE-2026-80731, DEBIAN-CVE-2026-80731, GHSA-534x-f2qc-fghv, UBUNTU-CVE-2026-80731.