From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f47.google.com (mail-yx1-f47.google.com [74.125.224.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 887BF48B363 for ; Tue, 5 May 2026 15:58:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777996692; cv=none; b=hf1acWN1kqYeAZbnowEaRO9a7TuEQhdDltjhoAXHDSh0mlS4RsClJlUA7WN0lR53K7q02PDXflouT58QU1dj0123N0We9MjW4gISlnR+Hxcs/4Axrf4lOJr2RztS+87MfNMZf2vPKcdSDRUUxWEentg+lC/WJROPK3pE8hsWryw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777996692; c=relaxed/simple; bh=D2o/PVb77AkBEhbzcdF37qpR3SjVgvH1lEK7F9GQx9U=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=J9o7OlejxsrQe9VXu1chZoApsW3GcRhDyh2fO0KNNXJl4MY1zcZIrt87I3ekZ7Opr9Vi1vVYo9x75FaRj77Al3YMi1ip6NUFOFK943Vmrl1/ddum81vTKu5xJ4fraQRFmRmJ6fGRE6JpBzXW0GqGXLCVhb4D0fP10jpF7wHwrD4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=joU5c9Tb; arc=none smtp.client-ip=74.125.224.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="joU5c9Tb" Received: by mail-yx1-f47.google.com with SMTP id 956f58d0204a3-651bf695701so5439291d50.2 for ; Tue, 05 May 2026 08:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777996689; x=1778601489; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=aejSiLDsfk8IAFtVBk+tM96P+lkGFUJjyUFGj4omje0=; b=joU5c9TbCxNdu75tqqmlGj2AKZq2aqA5+gJdigk0uZm0lq+uIzREpJl5uKCsAOlvzW LTeL5TaKPxtUdJE4u5gY05JYLuyfCldGCM2573grKPgAMLhqWGMAW+o9j3ns+bva6Ty2 L1elbmCtFtP+D3A+BDBNDiR8Fn0LaniOcXup6PXET9RlLfa2B5gKBjGfLynAKiPgG+EV qMppwOHPyZn3alRy+Sfxlg9VKR+ol8JFOuR/3dAYCj7s65amlzq7TBE0qvwOcKpDu7vr HR4TBKY03DgVDorDK4idCpI2xJn4Azr+Omn46Tlbq5DBYowG3/j8LGSd/alWffwfPA1+ 8cZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777996689; x=1778601489; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aejSiLDsfk8IAFtVBk+tM96P+lkGFUJjyUFGj4omje0=; b=QVwpN4DMx5mGgxu0FWpIl0wuSy9yaTyrWw8VsxPu+lvvX2+9qT1rlRrzgh9JoMCwGY phTHakENX/wMcRenMUCGECk75u8pvxEpctH6+aFN4NRwI596ib+aeZmmNzUJRnB+1Jgc JJ+5vhjgOzBXJnqhyYHQNH9Kr3WiVvqUVmyIp/TPnm7a9+i1AEv+TuHTSQ/GRaYuz72R 0hcwJlXZyGhxWyLnC0MlOwO+YZQHaw+RJhucMZhEJocslU1i3lWolIzbfKYvKi2es5I/ 4piqjmU0CO6J+wjLv+gygVf7/Y3XLISO0syjjM92vjx50FEBSHxrLHKFNGC2CBTx60m7 YgOw== X-Forwarded-Encrypted: i=1; AFNElJ+0Adnmh5SaHHN6JEi1mrt7Fn+vAUpBiWGJk+InTHfp7X0QYTslQpLF8TjzdFFDNg6usnEqdZ5JmqXxYkE=@vger.kernel.org X-Gm-Message-State: AOJu0YwvIeuHPCRQStFDxOdR7VpHxNaVOB7xYgk0rUatsBfkyMODhhNR 4PW6kr8i1Ph96a8HoZ2FdzAOfDZTCdCRPn8Ec2WETTwz47iAohRr+P0K X-Gm-Gg: AeBDievK5BdalcbbxkEP0Bt0DroZPvRR8ijgbZLokPdMr9fm9B3h/UoAMyhpRISmntC dCICRdw71Rd//BR7rhBlrpLiLCWOXdfGwE7DIcS17kU+1LMC+mFb6iUQb7siK+sNNM78D5+G3sL J8A4rADdwkJNI6L3MMbhgtxSUIqLzm1IC+DiNlJQQ2FK38txcExUST9WMKj2YSJ095gaAIvEW0c +TqwKPUFw2YqLPgbGQZHEeFgG6DPpPHT7E/wMLIWNb2q6yt+byRXYw3NT7Rfu6BfXWxM+2a6rmj r9Bs8yguVS6hJBSw2oHuPFEVJbSuuYVKuplOjAKSavbg+0jVvTTL02bEw8n4QSmUfn/dFLWTi4A b56zMlSDuZ0pnGo3aLM1pzH0v8wQqWyViSKI7RvAq+9pzBoZyhUgl47oa+Y+9tWBWaPDjH+qvWG +Vi2Zuv+meFXxjwN0LLWC7q4PzJPjZPy6EtHShcZYZrT2f3XQ8aAkRrSlLiVsAqOvRe3/0qRwDF 5eapxRlD3nYdXnB9Q4bUzr3AA== X-Received: by 2002:a53:b457:0:b0:65c:5b88:84a2 with SMTP id 956f58d0204a3-65c69c48b3cmr3048915d50.4.1777996689221; Tue, 05 May 2026 08:58:09 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-65c2e1d95a8sm7216162d50.9.2026.05.05.08.58.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 08:58:08 -0700 (PDT) Date: Tue, 05 May 2026 11:58:07 -0400 From: Willem de Bruijn To: Maoyi Xie , "David S . Miller" Cc: Jakub Kicinski , Paolo Abeni , Eric Dumazet , David Ahern , Alexey Kuznetsov , Willem de Bruijn , Willem de Bruijn , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Message-ID: In-Reply-To: <20260505072015.1672730-3-maoyi.xie@ntu.edu.sg> References: <20260505072015.1672730-1-maoyi.xie@ntu.edu.sg> <20260505072015.1672730-3-maoyi.xie@ntu.edu.sg> Subject: Re: [PATCH net v7 2/2] ipv6: flowlabel: enforce per-netns limit for unprivileged callers Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Maoyi Xie wrote: > fl_size, fl_ht and ip6_fl_lock in net/ipv6/ip6_flowlabel.c are > file scope and shared across netns. mem_check() reads fl_size to > decide whether to deny non-CAP_NET_ADMIN callers. capable() runs > against init_user_ns, so an unprivileged user in any non-init > userns can push fl_size past FL_MAX_SIZE - FL_MAX_SIZE / 4 and > starve every other unprivileged userns on the host. > > Add struct netns_ipv6::flowlabel_count, bumped and decremented > next to fl_size in fl_intern, ip6_fl_gc and ip6_fl_purge. The new > field fills the existing 4-byte hole after ipmr_seq, so struct > netns_ipv6 stays the same size on 64-bit builds. > > Bump FL_MAX_SIZE from 4096 to 8192. It has been 4096 since the > file was added. Machines and connection counts have grown. > > mem_check() folds an extra per-netns ceiling into the existing > non-CAP_NET_ADMIN conditional. The ceiling is half of the total > budget that unprivileged callers have ever been able to use, i.e. > (FL_MAX_SIZE - FL_MAX_SIZE / 4) / 2 = 3072 entries. With > FL_MAX_SIZE doubled, this preserves the original per-user reach > of 3K (what an unprivileged caller could already obtain before > this change), while forcing an attacker to spread allocations > across at least two netns to exhaust the global non-CAP_NET_ADMIN > budget. > > CAP_NET_ADMIN against init_user_ns still bypasses both caps. > > The previous patch took ip6_fl_lock across mem_check and > fl_intern, so the new flowlabel_count read in mem_check and the > new flowlabel_count++ in fl_intern run under the same critical > section. flowlabel_count is therefore plain int, like fl_size. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Suggested-by: Willem de Bruijn > Cc: stable@vger.kernel.org # v5.15+ > Signed-off-by: Maoyi Xie Reviewed-by: Willem de Bruijn