CVE-2026-80731 in Linux
Summary
by MITRE • 09/03/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel network stack contained a critical out-of-bounds write vulnerability within the net device header validation logic, specifically located in the dev_validate_header function. This flaw arose from an inconsistency between how buffer headroom was allocated for socket buffers and how that headroom size was validated during packet processing. When applications with CAP_SYS_RAWIO capabilities sent packets using variable-length Layer 2 protocols, the kernel would read the current value of dev->hard_header_len to determine if zero-padding was necessary for short headers. However, this validation step occurred after the buffer headroom had already been allocated based on a previous snapshot or calculation of hard_header_len. If the network device configuration changed concurrently such that dev->hard_header_len increased between the allocation and the validation steps, the subsequent memset operation intended to pad the header would write beyond the bounds of the reserved memory region. This constitutes an out-of-bounds write vulnerability where kernel memory is corrupted due to a race condition involving dynamic device reconfiguration.
From a technical perspective, this issue represents a classic time-of-check-to-time-of-use (TOCTOU) flaw combined with improper buffer boundary validation. The vulnerability leverages the fact that network devices can have their header length parameters modified while packets are in flight or being processed by different kernel threads. Although some SOCK_RAW paths previously masked this specific out-of-bounds write because a concurrent increase might cause skb_push to exceed reserved headroom and trigger an immediate panic, relying on such side effects is unsafe engineering practice. The transition from a loud crash to a silent memory corruption significantly increases the risk of exploitation for privilege escalation or denial of service attacks that do not immediately destabilize the system but may lead to data leakage or code execution later in the packet processing lifecycle.
The operational impact of this vulnerability allows an attacker with CAP_SYS_RAWIO privileges, which are typically held by root-level processes and certain network management tools, to corrupt kernel memory structures associated with network device headers. While the specific attack vector requires control over variable-length Layer 2 protocol parameters and concurrent modification of hard_header_len, the severity is heightened by the potential for silent data corruption. This aligns with CWE-787: Out-of-bounds Write in terms of vulnerability classification, as it involves writing to a memory location outside the intended buffer boundaries. In the context of the MITRE ATT&CK framework, this could facilitate lateral movement or persistence if exploited within a containerized environment where CAP_SYS_RAWIO is granted and network namespaces are manipulated dynamically.
To mitigate this risk, the Linux kernel maintainers removed the specific code branch that performed zero-padding for CAP_SYS_RAWIO holders in dev_validate_header. This change ensures that validation logic no longer attempts to write padding bytes based on potentially stale or inconsistent header length values after buffer allocation has occurred. The remaining reads of dev->hard_header_len were converted to simple comparisons, eliminating any memory safety impact from those operations. For system administrators and developers, this patch highlights the importance of ensuring consistency between resource allocation sizes and validation checks in high-concurrency network paths. Systems running affected kernel versions should be updated immediately to apply these fixes, thereby preventing potential exploitation through crafted packet sequences that exploit race conditions during device reconfiguration.