CVE-2026-74659 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mrp: fix uninitialised bytes on the wire
br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with
sub_tlv = skb_put(skb, sizeof(*sub_tlv)); sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR;
so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out.
Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified as CVE-2024-related involves an information leak within the Linux kernel's bridge Multiple Ring Protocol implementation, specifically in the function br_mrp_alloc_test_skb which constructs MRP test frames for network transmission. This issue arises from improper memory initialization practices when allocating and populating socket buffers used to carry protocol data units across the network interface. The core of the flaw lies in the use of dev_alloc_skb for buffer allocation, a standard kernel routine that allocates memory but does not guarantee zeroing out the linear data area. When constructing frames on the MRA ring-role branch, the code appends a sub-option TLV header using skb_put without subsequently initializing all fields within that structure. Specifically, while the type field is explicitly set to BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR, the length field remains uninitialized because no write operation targets it before transmission.
This lack of initialization results in three uninitialised bytes being transmitted as part of every MRA MRP_Test frame sent over the network interface. Although adjacent regions such as the oui and sub_opt fields are explicitly zeroed to ensure protocol compliance for those specific segments, the gap between explicit initializations leaves a small but critical window where kernel memory contents are exposed. These uninitialised bytes may contain sensitive data from previous allocations that reused the same memory slab, effectively creating an information leak vulnerability. An attacker with the ability to observe network traffic on the affected bridge interface could potentially capture these frames and extract fragments of internal kernel state, which might include pointers, cryptographic keys, or other confidential data residing in previously allocated buffers.
From a technical classification perspective, this flaw aligns with CWE-200: Information Exposure where uninitialised memory is disclosed to an unauthorized actor through network transmission. It also relates to CWE-457: Use of Uninitialized Variable since the length field within the sub-option TLV structure was accessed and transmitted without being assigned a deterministic value prior to use. In terms of adversarial tactics, this vulnerability could facilitate reconnaissance activities under MITRE ATT&CK technique T1082: System Information Discovery if an attacker leverages the leaked data to map internal system structures or infer memory layout for further exploitation attempts such as kernel address space layout randomization bypasses.
The operational impact is primarily centered on confidentiality rather than availability or integrity, although the presence of uninitialised data in network packets can also lead to protocol parsing errors if downstream systems expect strictly formatted headers. The severity is mitigated by the small size of the leak and the requirement for an attacker to have access to the specific bridge interface traffic, but it remains a significant concern due to the potential for cumulative information gathering over time. To mitigate this risk, developers must ensure that all memory regions intended for network transmission are explicitly zeroed or initialized before being populated with protocol-specific data.
The resolution implemented in the kernel involves refactoring the skb_put calls within br_mrp_alloc_test_skb to utilize skb_put_zero instead of the standard skb_put function. This change ensures that both the sub-option TLV header and any necessary alignment padding bytes are cleared upon allocation, thereby eliminating the uninitialised memory exposure. By using a single zeroing operation for these contiguous regions, the fix not only resolves the security flaw but also improves code clarity by acknowledging that the AUTO_MGR sub-TLV carries no payload beyond its header structure. This approach guarantees that the length field is correctly set to zero and that any padding bytes do not leak stale kernel data, thereby restoring full compliance with secure memory handling standards for network packet construction in Linux bridge implementations.