CVE-2026-74659 Overview
CVE-2026-74659 is an uninitialized memory disclosure vulnerability in the Linux kernel's bridge Media Redundancy Protocol (MRP) implementation. The flaw resides in br_mrp_alloc_test_skb(), which builds MRP test frames on an skb allocated via dev_alloc_skb(). That allocator does not zero the linear data area. On the Media Redundancy Automanager (MRA) ring-role branch, the sub-option TLV header length field and two trailing alignment bytes are never explicitly written, so three uninitialized kernel bytes leak into every MRA MRP_Test frame transmitted on the wire.
Critical Impact
Uninitialized kernel stack or heap memory is emitted onto the local Ethernet segment inside every outgoing MRA MRP_Test frame, potentially exposing sensitive kernel data to adjacent network observers.
Affected Products
- Linux kernel builds with CONFIG_BRIDGE_MRP enabled configured as an MRA (Media Redundancy Automanager) ring node
- Linux stable branches referenced by the seven backport commits published on git.kernel.org
- Bridge devices participating in IEC 62439-2 MRP ring topologies
Discovery Timeline
- 2026-08-22 - CVE CVE-2026-74659 published to NVD
- 2026-08-22 - Last updated in NVD database
Technical Details for CVE-2026-74659
Vulnerability Analysis
The Linux bridge MRP module implements IEC 62439-2 Media Redundancy Protocol for industrial ring topologies. When a bridge operates in the MRA ring role, br_mrp_alloc_test_skb() composes an MRP_Test frame by successively appending TLV structures to a socket buffer. The socket buffer is obtained through dev_alloc_skb(), which allocates from the SLAB/SLUB allocator without clearing the linear payload region.
The function correctly zeroes the oui and sub_opt fields but appends the sub-option TLV header using skb_put(skb, sizeof(*sub_tlv)) followed only by assignment of sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR. The adjacent sub_tlv->length byte is never written. A subsequent bare skb_put() reserves two alignment padding bytes without initialization. The result is a three-byte window of stale kernel memory embedded in each transmitted frame [CWE-908, CWE-200].
Root Cause
The root cause is reliance on dev_alloc_skb() semantics combined with per-field writes that leave structure members and padding untouched. Because kernel skb allocations may recycle memory previously used by unrelated subsystems, the leaked bytes can contain arbitrary residue including pointers, cryptographic material, or process data.
Attack Vector
Exploitation requires an attacker on the same Layer 2 segment as the MRA-configured bridge port. The attacker passively captures outbound MRP_Test frames, which are broadcast periodically as part of the ring health protocol. Each captured frame yields three bytes of unsanitized kernel memory, and repeated captures allow accumulation of information across the transmission stream. The vulnerability is not remotely reachable across routed boundaries, since MRP frames use a link-local multicast destination.
The upstream fix replaces the two separate skb_put() calls with a single skb_put_zero() invocation that clears both the sub-option TLV header and the alignment padding. Because the AUTO_MGR sub-TLV carries no payload, a zeroed length field is the correct on-the-wire value. Refer to the applicable kernel commits including 014c062d, 06d58b8d, 5912cf18, 63488dba, 7ebc23ff, a5e385ee, and e0866521 for the exact source change.
Detection Methods for CVE-2026-74659
Indicators of Compromise
- Passive capture of MRP_Test frames on ring ports where the sub_tlv->length byte or trailing two-byte alignment region contains non-zero values inconsistent with the AUTO_MGR sub-TLV specification
- Unexpected non-zero bytes at fixed offsets within outbound MRA MRP_Test frames when compared against a patched reference host
- Unauthorized packet capture activity or promiscuous-mode interfaces on hosts adjacent to MRP ring bridges
Detection Strategies
- Deploy Ethernet packet capture on ring links and diff MRA MRP_Test frame payloads across kernel versions to identify vulnerable emitters
- Inventory hosts running bridge kernel modules with MRP enabled by auditing /proc/net/bridge and modinfo bridge output at scale
- Correlate kernel version data with the fixed commits listed in the kernel.org stable references to identify unpatched systems
Monitoring Recommendations
- Enable telemetry on Linux endpoints and industrial gateway hosts to track loaded kernel versions and bridge module state
- Monitor for tcpdump, Wireshark, or raw AF_PACKET socket usage on hosts that share broadcast domains with MRP-participating bridges
- Alert on physical or virtual port mirroring configurations targeting MRP ring ports without change-control approval
How to Mitigate CVE-2026-74659
Immediate Actions Required
- Update affected Linux systems to a kernel version incorporating the skb_put_zero() fix referenced by the stable commits 014c062d, 06d58b8d, 5912cf18, 63488dba, 7ebc23ff, a5e385ee, and e0866521
- Identify bridges operating in MRA ring role and prioritize patching those hosts first, since only the MRA branch triggers the leak
- Restrict physical and logical access to Layer 2 segments carrying MRP traffic to trusted operational technology equipment only
Patch Information
The fix is available in the upstream Linux stable tree through seven backport commits published on git.kernel.org. Distribution vendors will ship the correction in kernel security updates that include these commits. Consult the following references: Kernel Patch 014c062d, Kernel Patch 06d58b8d, Kernel Patch 5912cf18, Kernel Patch 63488dba, Kernel Patch 7ebc23ff, Kernel Patch a5e385ee, and Kernel Patch e0866521.
Workarounds
- Disable the MRA ring role on affected bridges where MRP is not operationally required, reverting to a non-MRA MRP configuration or removing MRP entirely
- Segment MRP ring traffic onto dedicated VLANs or physical links inaccessible to general-purpose hosts and untrusted devices
- Enforce Layer 2 access controls such as MAC filtering and port security on switches carrying MRP frames until patched kernels are deployed
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
