In the Linux kernel, the following vulnerability has been resolved:
packet: use consistent hardheaderlen in non-ring send paths
packetsnd() reads dev->hardheader_len 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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74582.json"
}