CVE-2026-53245

What it actually does

This flaw is an input-validation bug in the Linux kernel Multiple Registration Protocol (MRP) parser. Malformed MRP vector attributes can cause the kernel to process an extra event, parse subsequent protocol data at the wrong offset, or apply an event to the wrong attribute value. The most likely technical impact is incorrect MRP applicant state handling and potential disruption of Layer 2 registration behavior on systems using kernel MRP functionality. The description does not indicate a confirmed memory-corruption primitive, privilege escalation path, or remote code execution capability.

Why it matters to the business

Organizations using Linux systems for bridging, switching, industrial networks, or other Layer 2 environments that rely on MRP could experience network registration instability or traffic forwarding disruption if malformed MRP frames are received. Because exploitation requires access to the local Layer 2 network and there is no known public exploit or KEV listing, the broad business risk is currently low, but exposed network infrastructure should still be patched during normal kernel maintenance cycles.

How an attack unfolds

An attacker positioned on the same Layer 2 segment as a vulnerable Linux system sends specially crafted MRP protocol data units containing malformed VectorAttribute fields. By choosing values where the vector length is zero, exactly divisible by three, or spans multiple event bytes, the attacker can trigger parser edge cases in the kernel. The vulnerable parser may consume bytes incorrectly, apply spurious events, or associate events with the wrong attribute value. This can corrupt MRP protocol state and may cause registration behavior to become inconsistent, potentially disrupting network operation for services depending on MRP.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for net/802/mrp mrp_pdu_parse_vecattr. If vendor distributions are used, apply the relevant vendor kernel security update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling unused MRP functionality, limiting untrusted access to Layer 2 segments where MRP is processed, and filtering unexpected MRP frames at switches or network access boundaries where operationally safe.

How to confirm the fix worked

Confirm that the running kernel package includes the patch that updates mrp_pdu_parse_vecattr to decrement valen after the third event, skip FirstValue parsing when valen is zero, and increment the attribute value correctly between event bytes. Validate through vendor advisory status, package changelogs, or source inspection of net/802/mrp.c. On running systems, confirm the active kernel version after reboot and verify that MRP functionality is either patched or not enabled/used. Network validation can include checking whether MRP frames are accepted from untrusted ports and whether controls exist to restrict unexpected EtherType 0x88f5 traffic.

Typical attack path

1. Gain access to the same Ethernet broadcast domain or Layer 2 segment as a vulnerable Linux host or bridge using MRP.
2. Craft MRP frames with malformed VectorAttribute encoding, such as valen equal to zero, valen divisible by three, or valen greater than three across event-byte boundaries.
3. Send the malformed MRP frames to the vulnerable system using the MRP EtherType and relevant multicast destination addresses.
4. Trigger incorrect parsing in the kernel MRP handler.
5. Cause incorrect MRP applicant state transitions, offset corruption during PDU parsing, or network registration instability.

How to detect it

There may be few or no host logs because this is a kernel network parser issue and malformed frames may only affect protocol state. To investigate possible exploitation, review network packet captures, SPAN/TAP data, switch telemetry, and IDS records for unexpected MRP traffic, especially EtherType 0x88f5 frames from untrusted hosts. Look for malformed MRP VectorAttribute encodings, including zero-length vectors with additional value data, vector lengths divisible by three followed by unexpected event bytes, or multi-byte vectors where attribute progression appears inconsistent. Review kernel logs for network, bridge, MRP, or unexpected interface instability messages around the same time as suspicious Layer 2 traffic. In operational environments, correlate suspicious MRP frames with VLAN or multicast registration anomalies, link instability, forwarding issues, or sudden changes in Layer 2 registration state.

• ether proto 0x88f5
• eth.type == 0x88f5
• 01:80:c2:00:00:20
• 01:80:c2:00:00:21
• MRP VectorAttribute
• LeaveAllEvent
• mrp_pdu_parse_vecattr
• net/802/mrp.c

What your security team should do

• Identify Linux systems acting as bridges, switches, virtual switches, industrial gateways, or other Layer 2 devices where kernel MRP support may be enabled or reachable.
• Prioritize patching systems that process MRP on shared, exposed, industrial, campus, or multi-tenant Layer 2 networks.
• Apply vendor kernel updates that contain the fix and reboot into the updated kernel.
• If patching is delayed, restrict MRP traffic to trusted switch ports and block unexpected EtherType 0x88f5 frames where this does not break operations.
• Review packet captures and network telemetry for malformed or unexpected MRP traffic, especially from untrusted endpoints.
• Monitor vendor advisories for affected kernel branches and distribution-specific fixed package versions, since none were provided in the input.
• Because EPSS is low, the issue is not KEV-listed, and no exploit maturity is reported, handle this as routine-priority patching unless MRP is exposed in a high-impact operational network.