From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67A8F1FE471 for ; Thu, 6 Aug 2026 13:08:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786021714; cv=none; b=Eu0Rfa/vFU6ixBgIZLtceHdMYrq4m9MofyjGKFviWGSHNBdovp1vphv0Zpt4odQm98DsYpxz/XCZbDGJa+pF422WE8+z8cjdVNZ2O1iXoS0G0NJoJN+kB4aCbnSGRNV5XSBgH1/gcA+ZQUmaZoa4jEpWA72NHdvxkCKObI9hphM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786021714; c=relaxed/simple; bh=OKBgE1zco51TS+bnUGKw3JCA3xNVFMZtwavXxzMaGl0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BeBnsJKFmJnJwHxTjLlE4a36kkaaBspjg+dSg5uFnG9c6947w0inU5NQZ+FKq8jrglXeLY1UkxE0Y25sZUOCytvgR2cdOr4HxeYjrRVY0+pzgXD2mcI167/xkkUfZYhVw1L2Ce6M/7mzQeAyjXrOyBmHnTp/RIUK6y+mdGTCRsU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eDpeCkuf; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=E4lpL5Xz; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eDpeCkuf"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="E4lpL5Xz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786021712; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Loby3/i2NagUTDWGI/ZUcbVav8fDPEU/GK5BwQZ1+vs=; b=eDpeCkufuAz26uJwS72IGZ/VDgiDUG9C36KrxV7tfZLHK36U+GZD028oHDxf9/QMLc9aMS 8ZVmu6Qu3flZteMcU6RGPQTOt46JB9szOQbr70Jvx6byNP3nBppaRmjgLE9IKs6iyGnXTs +K9DBbNFLUHxI8mPiIxiJMHlvaerp8U= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-292-vw1LTNy8POO2RASgKGOQLA-1; Thu, 06 Aug 2026 09:08:25 -0400 X-MC-Unique: vw1LTNy8POO2RASgKGOQLA-1 X-Mimecast-MFC-AGG-ID: vw1LTNy8POO2RASgKGOQLA_1786021704 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-47f81362fb1so1325031f8f.1 for ; Thu, 06 Aug 2026 06:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786021704; x=1786626504; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Loby3/i2NagUTDWGI/ZUcbVav8fDPEU/GK5BwQZ1+vs=; b=E4lpL5Xzu8YIsdVRAQHN/gGqRTZZbhJZp4rDRzoeEzUgCoRNm+DsxYL8SA50uucKJg /7GpxX/UKu0TcOc1pLSRsLHD6OEuk4psPKx14kRE/425G+XfcoZJQTwqDmiSwEnAtpWF NPbt86QQrePGD+BjqW2zcF3zwDM/hxyBjP4ctNwRHo2d9bxDN5YHXR//1XitT3RZTf17 Z9B/jkva6ri8senk7xgljhPPEkB9UV+LAY+h1fksjQ2KFIvsQgMiBzZDnz9KebDeBy08 N9GFfFtB5q4O0ZfelQ7FrIFWuZOrO8N5Z+67eKC+m6X7ZJuILSvHfxJ/CGyABnM5/Vi5 9V9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786021704; x=1786626504; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Loby3/i2NagUTDWGI/ZUcbVav8fDPEU/GK5BwQZ1+vs=; b=PqfCm7fSV1cKHfvAU6KNJt/WqmmVQDtKn8qMM1pCRSUgOdEXBaLzV0Dd4n8Rhsh7hi wh3XkMM/C8fSaoFIK93m1e0Qkfw8+rNRAycuRpAkeJkEglAi80IrGRjpnof5aPhVm0Xz eiiEprH44XI7kxkbixwIQ2GNBlDB04yrWjOKhyjBcdZsYzKRj7zMg9jwjO5usO1ahf6g ThpcDcCM++4p7v3bO5qhmCFxJhAV7iwfgenjtZbr2RxFnkJBC8inUfVwEoSR9EgS/AwI WxU4+NpWp50mZorbmCof5xY8M0gY8uhwNzUtVhYnB6sA7Z8MKZKCTuwRhI5R5i22W7k4 rYSg== X-Forwarded-Encrypted: i=1; AHgh+RqKO0F+mxTT0ZtFSIwPMcghNTPXXoT/tsHxA8Zy6idXYvCC2fHIblGlM73FqdDUE7Vh+dLclnSKjUJk0lY=@vger.kernel.org X-Gm-Message-State: AOJu0YyMI+w54ElBSLn5ccxacw/uwS9/3BmFyRzbTzqtp0m1j3vseWNu U3WCzvpgBv4ASb343fyQm613PTydENfG5wTy9cHG2gpsvHIWuGXz8oqZ7K87E5Ta3IA0vNvREVI N+I78O1wG2COAUQtmxx4tXpUsbWnQEcXeAotel1ragvpUZjPZrPYYaFzLrWZCCwa67A== X-Gm-Gg: AR+sD12r+9YoFzjD1O0tcRigqxlsLB7GTZ5bM3pRJOjwSklrCsgGyEHrg3z9r5+KMay l2H4NASb4RV4mae+cZpEWB8EhrT5Aj5ed2hp+ig0rrJVm7GsjaNQn7skkd7H6bYEN5Bgf6aA3mw wG5XjZd3HL78fAQTOJ1VSV28sqtEup+rvrmldYGha9tXfG6W8pULwuoVZOUGN45KycGQ9Pr1Orx Rjqo4KnhEpOyBag8vq3pG49Gtq9gvuRybOmgD+lwYm7gIbSmkL16Hlp34ZV49jXbSnxk84YWL/7 5Z3oNJ2MS0lT8k7HQ1i4xlrV7JJcq3oUOpnm9jk+DCX0zI1BELinW4oQ13gSvNlRvA3myc/FFbo NckWAXrCZptfU2O/dwuloKl2N+EA1RwNxlGM8aWB1C7CFS88ZzZbbX0LDt9OZD96/CEQeRH4BA3 o= X-Received: by 2002:a05:6000:604:b0:47f:7526:598 with SMTP id ffacd0b85a97d-47fec5037eamr22742477f8f.12.1786021703979; Thu, 06 Aug 2026 06:08:23 -0700 (PDT) X-Received: by 2002:a05:6000:604:b0:47f:7526:598 with SMTP id ffacd0b85a97d-47fec5037eamr22742391f8f.12.1786021703523; Thu, 06 Aug 2026 06:08:23 -0700 (PDT) Received: from [192.168.188.103] (ip239-44-231-195.pool-bba.aruba.it. [195.231.44.239]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47ff7b183b2sm6802661f8f.24.2026.08.06.06.08.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2026 06:08:22 -0700 (PDT) Message-ID: <7dac738b-3ea2-430e-9513-2702c426a057@redhat.com> Date: Thu, 6 Aug 2026 15:08:21 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v2] macvlan: require lower-netns admin for shared port settings To: Doruk Tan Ozturk , andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org Cc: xmei5@asu.edu, thomas.karlsson@paneda.se, herbert@gondor.apana.org.au, daniel@iogearbox.net, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260802130137.98105-1-doruk@0sec.ai> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260802130137.98105-1-doruk@0sec.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/2/26 3:01 PM, Doruk Tan Ozturk wrote: > struct macvlan_port is per lower device and is shared by every macvlan > upper on it, including uppers that live in other network namespaces. > Two of its fields are settable over rtnetlink by any upper on the port: > port->bc_cutoff, written by IFLA_MACVLAN_BC_CUTOFF, and > port->bc_queue_len_used, recomputed from IFLA_MACVLAN_BC_QUEUE_LEN. > (port->flags and port->perm_addr are also rtnetlink-settable, but only > in passthru mode, which requires port->count == 0 and so cannot be > reached from a second upper.) > > rtnetlink checks CAP_NET_ADMIN against the network namespace the > configured device lives in and nothing else, so once a macvlan has been > moved into a child network namespace, an administrator of that namespace > alone reaches macvlan_changelink(), which applies both attributes > without considering who owns the lower device. > > The create path has the same gap. macvlan_common_newlink() resolves a > lower device that is itself a macvlan to the real lower device: > > if (netif_is_macvlan(lowerdev)) > lowerdev = macvlan_dev_real_dev(lowerdev); > > That real device may sit in a network namespace that was never > capability-checked. The new upper then joins its macvlan_port and runs > update_port_bc_queue_len() on it, and, when IFLA_MACVLAN_BC_CUTOFF is > present, update_port_bc_cutoff(). > > port->bc_cutoff is not a local tuning knob. update_port_bc_cutoff() > recomputes port->bc_filter, which macvlan_handle_frame() tests to decide > whether a multicast frame is deferred to the port broadcast work queue > or flooded inline from the RX softirq, and a negative cutoff clears > bc_filter outright. A namespace that administers none of the other > uppers can therefore change how all of them receive multicast. > > Reproduced on 6.8 with a dummy lower device and two macvlan uppers, one > left in the initial namespace and one moved into a child user and > network namespace. From the child, both a changelink and a nested > newlink carrying IFLA_MACVLAN_BC_CUTOFF were accepted, and the value > read back on the initial-namespace sibling followed them, changing from > 1 to -7 and then to -42. > > Require CAP_NET_ADMIN in the lower device network namespace before > applying a shared port setting or creating a macvlan on a flattened > lower device. rtnl_dev_link_net_capable() short-circuits when the lower > device shares the macvlan network namespace, so an ordinary > single-namespace configuration is unaffected, and per-upper settings > such as mode and flags stay available to an administrator of the > macvlan's own namespace. This is the model ipvlan has used since > commit 7cc9f7003a96 ("ipvlan: disallow userns cap_net_admin to change > global mode/flags"). > > Found by 0sec automated security-research tooling (https://0sec.ai). > > The newlink gate is unconditional rather than keyed on a BC attribute > being present, because joining another namespace's macvlan_port is > itself a mutation of shared state; ipvlan gates ipvlan_link_new() the > same way. > > IFLA_MACVLAN_BC_QUEUE_LEN is gated here as well as by any magnitude > check, because the two address different things: a magnitude check > bounds how large a value any caller may request, while this bounds who > may write the shared port at all. update_port_bc_queue_len() takes the > maximum across uppers, so a cross-namespace lowering has no security > effect and this over-rejects it; that is accepted in exchange for one > rule covering every writer of the shared struct. > > Fixes: d4bff72c8401 ("macvlan: Support for high multicast packet rate") > Fixes: 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff") > Cc: stable@vger.kernel.org > Assisted-by: 0sec:multi-model > Signed-off-by: Doruk Tan Ozturk I think that following ipvlan example is correct, but the behavior change may break existing user; we don't want bad regression this late. I think this is more suitable for net-next, with no fixes tag. /P