Bug 2519475 (CVE-2026-74582)

Summary: CVE-2026-74582 kernel: packet: use consistent hard_header_len in non-ring send paths
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
An out-of-bounds write problem was observed in packet_sendmsg_spkt in net/packet/af_packet.c in the Linux Kernel. In this flaw, AF_PACKET hard_header_len race may allow local privilege escalation.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-19 10:18:37 UTC
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.

Comment 4 errata-xmlrpc 2026-08-27 12:41:05 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions

Via RHSA-2026:60484 https://access.redhat.com/errata/RHSA-2026:60484

Comment 5 errata-xmlrpc 2026-08-27 12:51:57 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.6 Extended Update Support

Via RHSA-2026:60486 https://access.redhat.com/errata/RHSA-2026:60486

Comment 6 errata-xmlrpc 2026-09-02 12:29:40 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10.0 Extended Update Support

Via RHSA-2026:62609 https://access.redhat.com/errata/RHSA-2026:62609

Comment 7 errata-xmlrpc 2026-09-04 08:14:47 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.8 Update Services for SAP Solutions
  Red Hat Enterprise Linux 8.8 Telecommunications Update Service

Via RHSA-2026:63537 https://access.redhat.com/errata/RHSA-2026:63537

Comment 8 errata-xmlrpc 2026-09-09 00:35:53 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support
  Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On

Via RHSA-2026:65710 https://access.redhat.com/errata/RHSA-2026:65710

Comment 9 errata-xmlrpc 2026-09-09 00:40:43 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support
  Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On

Via RHSA-2026:65711 https://access.redhat.com/errata/RHSA-2026:65711