CVE-2026-80731: net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header

Published Sep 3, 2026
·
Updated

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

1 affected component
Linux Linux kernel

Event History

Sep 3, 2026
CVE Published
via MITRE·08:21 AM
Data Sourced
via MITRE·08:21 AM
Description

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203