CVE-2026-74582: packet: use consistent hard_header_len in non-ring send paths

Greg Kroah-Hartman <[email protected]>
Newsgroups org.kernel.vger.linux-cve-announce
Message-ID <2026082100-CVE-2026-74582-3296@gregkh>
From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

packet: use consistent hard_header_len in non-ring send paths

packet_snd() reads dev->hard_header_len multiple times while allocating
and constructing an skb. Device reconfiguration can change this value
concurrently, for example through bonding device type changes.

For SOCK_RAW, packet_snd() 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.

packet_sendmsg_spkt() 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 LL_RESERVED_SPACE_EX() for callers that already saved a header length.
Read hard_header_len once in packet_snd() and use it for allocation and
construction. In packet_sendmsg_spkt(), preserve the allocation-time value
through the device lookup retry.

The separate SOCK_DGRAM consistency problem between hard_header_len and
header_ops->create is not addressed here.

The Linux kernel CVE team has assigned CVE-2026-74582 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.17 with commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba and fixed in 6.6.152 with commit 91f041451f967cd87ed722a8f43c0b767a64f1a0
	Issue introduced in 4.17 with commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba and fixed in 6.12.104 with commit 9052756290962ffb9a661bcf319e92dedaaedfed
	Issue introduced in 4.17 with commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba and fixed in 6.18.45 with commit 5bb10753d428aadfc356a2bfe9acea09c82a62ec
	Issue introduced in 4.17 with commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba and fixed in 7.1.9 with commit b06b6fce6d7deaf7238e09b48ce3b1125ff41acd
	Issue introduced in 4.17 with commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba and fixed in 7.2 with commit 03390aa32e669cc4ecd7d34108e2e1afc13d689d
	Issue introduced in 4.4.133 with commit d9fb8cc230b2a4757e9fe4f81468f81212d4deaa
	Issue introduced in 4.9.103 with commit 6190cce26e40bf71c4d375b21eea74bb07b6a0f3
	Issue introduced in 4.14.44 with commit 01a658c1b9d4b5393c38d5a92d9112ab1425382a
	Issue introduced in 4.16.12 with commit 8809ae6747e760e6f1d2453ceb08c9bcc4939766

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74582
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	include/linux/netdevice.h
	net/packet/af_packet.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/91f041451f967cd87ed722a8f43c0b767a64f1a0
	https://git.kernel.org/stable/c/9052756290962ffb9a661bcf319e92dedaaedfed
	https://git.kernel.org/stable/c/5bb10753d428aadfc356a2bfe9acea09c82a62ec
	https://git.kernel.org/stable/c/b06b6fce6d7deaf7238e09b48ce3b1125ff41acd
	https://git.kernel.org/stable/c/03390aa32e669cc4ecd7d34108e2e1afc13d689d
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.