CVE-2026-74582: packet: use consistent hard_header_len in non-ring send paths
In the Linux kernel, the following vulnerability has been resolved:
packet: use consistent hardheaderlen in non-ring send paths
packetsnd() reads dev->hardheaderlen multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes.
For SOCKRAW, packetsnd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write.
packetsendmsgspkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb.
Add LLRESERVEDSPACEEX() for callers that already saved a header length. Read hardheaderlen once in packetsnd() and use it for allocation and construction. In packetsendmsgspkt(), preserve the allocation-time value through the device lookup retry.
The separate SOCKDGRAM consistency problem between hardheaderlen and headerops->create is not addressed here.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the out-of-bounds write?
An attacker needs to use affected non-ring packet socket send paths while the target network device's hard_header_len changes concurrently. The described trigger includes device reconfiguration such as bonding device type changes, and the explicit out-of-bounds write scenario applies to SOCK_RAW.
Which packet socket paths are affected?
The issue is described in packet_snd() and packet_sendmsg_spkt(), which can derive reservation or header values from inconsistent reads of dev->hard_header_len. Ring-based send paths are not identified as affected.
Does this fix address all hard_header_len consistency issues for packet sockets?
No. The described fix does not address the separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create.