On 28/03/2026 02:19, Jakub Kicinski wrote:
On Fri, 27 Mar 2026 13:46:39 +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.
Then again if there's no practical use for 0 we should consider
the risk of getting this sort of submission over and over again?
Dunno..
Sure, I'm fine either way. To that end the patch looks good, just need the
fixes tag as mentioned earlier.
