CVE-2026-31420
Description
In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A zero test interval in Linux bridge MRP can cause OOM panic by scheduling work with no delay, fixed by enforcing a minimum interval via netlink policy.
The vulnerability resides in the Linux kernel's bridge MRP (Media Redundancy Protocol) implementation. The functions br_mrp_start_test() and br_mrp_start_in_test() accept a user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) returns 0, causing the delayed work items to reschedule with zero delay, creating a tight loop that transmits MRP test frames at maximum rate [1][2].
To exploit this, an attacker needs the ability to send a crafted netlink message to the bridge MRP subsystem, which typically requires CAP_NET_ADMIN privileges. No authentication beyond that is needed. By setting the test interval to 0, the attacker triggers an infinite loop of workqueue scheduling and network transmission, consuming CPU and memory resources rapidly.
The impact is a denial of service (DoS) via OOM panic, as the system exhausts all memory due to the continuous allocation and transmission of test frames. The vulnerability has a CVSS score of 5.5 (Medium).
The fix introduces NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for the relevant netlink attributes, ensuring zero values are rejected at the parsing layer before reaching the workqueue scheduling code. The patch has been applied to stable kernel trees [1][2].
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
2News mentions
1- Patch Tuesday - April 2026Rapid7 Blog · Apr 14, 2026