Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic

On Fri, Apr 03, 2026 at 09:34:15AM +0100, Simon Horman wrote:
> On Fri, Mar 27, 2026 at 01:46:39PM +0200, Nikolay Aleksandrov wrote:
> > On 27/03/2026 13:34, Simon Horman wrote:
> > > On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
> > > > 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.
> > > 
> > > I would suspect the primary outcome of this problem is high CPU consumption
> > > rather than memory exhaustion. Is there a reason to expect that
> > > the transmitted fames can't be consumed as fast as they are created?
> > > 
> > 
> > +1
> > More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
> > conditions. This is a configuration error and OOM doesn't lead to panic unless
> > instructed to. I don't think this is worth changing at all.
> 
> Right, I was getting to think that too.
> 
> ...


Thank you for the review.

Regarding the privilege argument: this path is reachable from an
unprivileged user namespace, which checks CAP_NET_ADMIN against the
network namespace's user_ns. An unprivileged user can create a 
user+net namespace, obtain CAP_NET_ADMIN within it, set up a bridge
with MRP, and trigger the zero-interval loop. So this crosses a 
security boundary.

Regarding the OOM behavior: this does lead to a kernel panic without
panic_on_oom or oops=panic. The zero-delay workqueue loop allocates
memory from kernel context continuously. The OOM killer fires and kills
all related userspace processes, but the memory pressure originates 
from a kernel workqueue which the OOM killer cannot target. Once no 
killable processes remain, the kernel hits "System is deadlocked on 
memory" and panics. Below is the relevant dmesg from a test without
oops=panic:

[    5.254108] Kernel panic - not syncing: System is deadlocked on memory
[    5.254470] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 7.0.0-rc4+ #6
[    5.255524] Call Trace:
[    5.255796]  vpanic+0x694/0x780
[    5.256607]  out_of_memory+0x124e/0x1350
[    5.257281]  __alloc_pages_slowpath.constprop.0+0x2325/0x2dd0
[    5.258777]  __alloc_frozen_pages_noprof+0x4f8/0x800     

Best,
Xiang