macvlan: require init-userns CAP_NET_ADMIN to raise bc_queue_len

IFLA_MACVLAN_BC_QUEUE_LEN accepts any u32 and becomes
port->bc_queue_len_used, the only bound on port->bc_queue. rtnetlink checks
CAP_NET_ADMIN against the target netns only, so a user who unshares a
user+net namespace, creates a veth and puts a macvlan on it can set the
backlog to 0xffffffff and flood broadcast frames until the host dies:

  Out of memory: Killed process 141 (su) UID:0
  Kernel panic - not syncing: System is deadlocked on memory
  Call Trace:
   vpanic (kernel/panic.c:650)
   panic (kernel/panic.c:787)
   out_of_memory (mm/oom_kill.c:1166)
   __alloc_frozen_pages_noprof (mm/page_alloc.c:4914)
   alloc_pages_mpol (mm/mempolicy.c:2490)
   folio_alloc_noprof (mm/mempolicy.c:2591)
   filemap_fault (mm/filemap.c:3565)

A fixed upper bound does not work. Deployments carrying 600-800 real-time
audio streams run bc_queue_len=100000, and no constant serves both cases:
the queue counts skbs, not bytes, and the frame size is attacker-chosen too
(up to ETH_MAX_MTU on a veth the caller creates).

Gate the elevated range on CAP_NET_ADMIN in the initial user namespace
instead. A backlog of that size is a host-wide tuning decision, and an
unprivileged owner of a namespace it created itself should not be able to
make it; privileged configurations keep working unchanged..

Cc: stable+noautosel@kernel.org # local DoS by userns are a dime a dozen
Reported-by: AutonomousCodeSecurity@microsoft.com
Link: https://lore.kernel.org/r/20260706212556.3199234-1-xmei5@asu.edu
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Link: https://patch.msgid.link/20260729200621.2521588-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

0 files changed, 0 insertions, 0 deletions