CVE-2026-74659: net: bridge: mrp: fix uninitialised bytes on the wire
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mrp: fix uninitialised bytes on the wire
brmrpalloctestskb() builds MRP test frames on an skb from devallocskb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with
subtlv = skbput(skb, sizeof(subtlv)); subtlv->type = BRMRPSUBTLVHEADERTESTAUTOMGR;
so subtlv->length is never written, and the two trailing alignment bytes are appended with a bare skbput() that does not clear them either. The neighbouring oui and subopt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRPTest frame that goes out.
Put the sub-option TLV header and the alignment padding in a single skbputzero(), which clears both. The AUTOMGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel bridge MRP implementation are exposed when they generate MRP_Test frames on the MRA ring-role branch. The issue affects frames transmitted from the affected system, where three uninitialised bytes can be placed on the wire.
What must occur for information to be disclosed?
An affected system must construct and transmit an MRA MRP_Test frame. The uninitialised data is in the AUTO_MGR sub-option TLV length field and trailing alignment padding, so an observer able to receive those frames could obtain the leaked bytes.
What is the remediation?
Apply a kernel update containing the fix referenced in the supplied stable kernel commits. The fix uses zero-initialized allocation for the sub-option TLV header and its alignment padding, ensuring the length and padding bytes are cleared.