CVE-2026-31420
Use-After-Free in Linux Bridge MRP Causes OOM Panic
Publication date: 2026-04-13
Last updated on: 2026-04-13
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, ensure that the Linux kernel rejects zero interval values for MRP test frames by applying the patch that uses 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.
This prevents zero values from being accepted at the netlink attribute parsing layer, avoiding the scheduling of delayed work with zero delay that causes a tight loop and eventual out-of-memory panic.
If a patch is not yet applied, avoid setting the MRP test interval to zero and monitor for any unusual kernel panics related to memory exhaustion.
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's bridge module related to the Multiple Registration Protocol (MRP). Specifically, functions br_mrp_start_test() and br_mrp_start_in_test() accept a user-supplied interval value without validating it. If the interval is set to zero, the system schedules a delayed work task with zero delay, causing it to run in a tight loop.
This tight loop continuously allocates and transmits MRP test frames at maximum rate, which exhausts all system memory and leads to a kernel panic due to an out-of-memory (OOM) deadlock.
The vulnerability is fixed by enforcing a minimum interval value of 1 at the netlink attribute parsing layer, preventing zero values from reaching the workqueue scheduling code.
How can this vulnerability impact me? :
If exploited, this vulnerability can cause the Linux system to enter a kernel panic due to an out-of-memory deadlock. This happens because the system continuously schedules and executes MRP test frames without delay, consuming all available memory.
The impact includes system instability, crashes, and potential denial of service, which can disrupt normal operations and availability of services running on the affected system.