CVE-2026-74668: packet: use consistent hard_header_len in TX_RING send path
In the Linux kernel, the following vulnerability has been resolved:
packet: use consistent hardheaderlen in TXRING send path
tpacketsnd() reads dev->hardheaderlen independently for skb allocation and header construction in tpacketfillskb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hardheaderlen negative.
Snapshot hardheaderlen once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacketfillskb().
The separate SOCKDGRAM consistency problem between hardheaderlen and headerops->create is not addressed here.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger the flaw?
The TX_RING send path must be in use while the network device's hard_header_len is changed concurrently. The race can cause insufficient reserved headroom or a negative copy-length calculation.
Does this resolution cover the related SOCK_DGRAM header consistency issue?
No. The described resolution does not address the separate consistency problem between hard_header_len and header_ops->create for SOCK_DGRAM.