From nobody Sun Jun 28 01:49:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90145C43219 for ; Wed, 16 Feb 2022 15:59:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235846AbiBPP7a (ORCPT ); Wed, 16 Feb 2022 10:59:30 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233462AbiBPP72 (ORCPT ); Wed, 16 Feb 2022 10:59:28 -0500 X-Greylist: delayed 141 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 16 Feb 2022 07:59:14 PST Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3D392A39CB; Wed, 16 Feb 2022 07:59:10 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:57886) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMhu-009IKW-FJ; Wed, 16 Feb 2022 08:59:06 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37452 helo=localhost.localdomain) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMht-002YPH-8X; Wed, 16 Feb 2022 08:59:06 -0700 From: "Eric W. Biederman" To: linux-kernel@vger.kernel.org Cc: Alexey Gladkov , Kees Cook , Shuah Khan , Christian Brauner , Solar Designer , Ran Xiaokai , containers@lists.linux-foundation.org, =?UTF-8?q?Michal=20Koutn=C3=BD?= , linux-api@vger.kernel.org, "Eric W. Biederman" , stable@vger.kernel.org Date: Wed, 16 Feb 2022 09:58:28 -0600 Message-Id: <20220216155832.680775-1-ebiederm@xmission.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> References: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1nKMht-002YPH-8X;;;mid=<20220216155832.680775-1-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19NThaI6BizHvKGbIpdTGv716FzPhyOfYM= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH v2 1/5] rlimit: Fix RLIMIT_NPROC enforcement failure caused by capability calls in set_user X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Solar Designer wrote: > I'm not aware of anyone actually running into this issue and reporting > it. The systems that I personally know use suexec along with rlimits > still run older/distro kernels, so would not yet be affected. > > So my mention was based on my understanding of how suexec works, and > code review. Specifically, Apache httpd has the setting RLimitNPROC, > which makes it set RLIMIT_NPROC: > > https://httpd.apache.org/docs/2.4/mod/core.html#rlimitnproc > > The above documentation for it includes: > > "This applies to processes forked from Apache httpd children servicing > requests, not the Apache httpd children themselves. This includes CGI > scripts and SSI exec commands, but not any processes forked from the > Apache httpd parent, such as piped logs." > > In code, there are: > > ./modules/generators/mod_cgid.c: ( (cgid_req.limits.limit_nproc_se= t) && ((rc =3D apr_procattr_limit_set(procattr, APR_LIMIT_NPROC, > ./modules/generators/mod_cgi.c: ((rc =3D apr_procattr_limit_set(pr= ocattr, APR_LIMIT_NPROC, > ./modules/filters/mod_ext_filter.c: rv =3D apr_procattr_limit_set(proc= attr, APR_LIMIT_NPROC, conf->limit_nproc); > > For example, in mod_cgi.c this is in run_cgi_child(). > > I think this means an httpd child sets RLIMIT_NPROC shortly before it > execs suexec, which is a SUID root program. suexec then switches to the > target user and execs the CGI script. > > Before 2863643fb8b9, the setuid() in suexec would set the flag, and the > target user's process count would be checked against RLIMIT_NPROC on > execve(). After 2863643fb8b9, the setuid() in suexec wouldn't set the > flag because setuid() is (naturally) called when the process is still > running as root (thus, has those limits bypass capabilities), and > accordingly execve() would not check the target user's process count > against RLIMIT_NPROC. In commit 2863643fb8b9 ("set_user: add capability check when rlimit(RLIMIT_NPROC) exceeds") capable calls were added to set_user to make it more consistent with fork. Unfortunately because of call site differences those capables calls were checking the credentials of the user before set*id() instead of after set*id(). This breaks enforcement of RLIMIT_NPROC for applications that set the rlimit and then call set*id() while holding a full set of capabilities. The capabilities are only changed in the new credential in security_task_fix_setuid(). The code in apache suexec appears to follow this pattern. Commit 909cc4ae86f3 ("[PATCH] Fix two bugs with process limits (RLIMIT_NPROC)") where this check was added describes the targes of this capability check as: 2/ When a root-owned process (e.g. cgiwrap) sets up process limits and th= en calls setuid, the setuid should fail if the user would then be running more than rlim_cur[RLIMIT_NPROC] processes, but it doesn't. This pat= ch adds an appropriate test. With this patch, and per-user process limit imposed in cgiwrap really works. So the original use case also of this check also appears to match the broken pattern. Restore the enforcement of RLIMIT_NPROC by removing the bad capable checks added in set_user. This unfortunately restores the inconsistencies state the code has been in for the last 11 years, but dealing with the inconsistencies looks like a larger problem. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20210907213042.GA22626@openwall.com/ Link: https://lkml.kernel.org/r/20220212221412.GA29214@openwall.com Fixes: 2863643fb8b9 ("set_user: add capability check when rlimit(RLIMIT_NPR= OC) exceeds") History-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.= git Signed-off-by: "Eric W. Biederman" Reviewed-by: Solar Designer --- kernel/sys.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/sys.c b/kernel/sys.c index ecc4cf019242..8dd938a3d2bf 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -480,8 +480,7 @@ static int set_user(struct cred *new) * failure to the execve() stage. */ if (is_ucounts_overlimit(new->ucounts, UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT= _NPROC)) && - new_user !=3D INIT_USER && - !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) + new_user !=3D INIT_USER) current->flags |=3D PF_NPROC_EXCEEDED; else current->flags &=3D ~PF_NPROC_EXCEEDED; --=20 2.29.2 From nobody Sun Jun 28 01:49:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2BC0C433EF for ; Wed, 16 Feb 2022 15:59:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235860AbiBPP7d (ORCPT ); Wed, 16 Feb 2022 10:59:33 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235811AbiBPP72 (ORCPT ); Wed, 16 Feb 2022 10:59:28 -0500 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D89822A797C; Wed, 16 Feb 2022 07:59:11 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:51766) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMhw-00Facl-Uw; Wed, 16 Feb 2022 08:59:08 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37452 helo=localhost.localdomain) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMhv-002YPH-QG; Wed, 16 Feb 2022 08:59:08 -0700 From: "Eric W. Biederman" To: linux-kernel@vger.kernel.org Cc: Alexey Gladkov , Kees Cook , Shuah Khan , Christian Brauner , Solar Designer , Ran Xiaokai , containers@lists.linux-foundation.org, =?UTF-8?q?Michal=20Koutn=C3=BD?= , linux-api@vger.kernel.org, "Eric W. Biederman" , stable@vger.kernel.org Date: Wed, 16 Feb 2022 09:58:29 -0600 Message-Id: <20220216155832.680775-2-ebiederm@xmission.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> References: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1nKMhv-002YPH-QG;;;mid=<20220216155832.680775-2-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19jMI1eR5e/rjuLRVwV70HFF3fBrIweiqc= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH v2 2/5] ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1 X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Koutn=C3=BD wrote: > It was reported that v5.14 behaves differently when enforcing > RLIMIT_NPROC limit, namely, it allows one more task than previously. > This is consequence of the commit 21d1c5e386bc ("Reimplement > RLIMIT_NPROC on top of ucounts") that missed the sharpness of > equality in the forking path. This can be fixed either by fixing the test or by moving the increment to be before the test. Fix it my moving copy_creds which contains the increment before is_ucounts_overlimit. In the case of CLONE_NEWUSER the ucounts in the task_cred changes. The function is_ucounts_overlimit needs to use the final version of the ucounts for the new process. Which means moving the is_ucounts_overlimit test after copy_creds is necessary. Both the test in fork and the test in set_user were semantically changed when the code moved to ucounts. The change of the test in fork was bad because it was before the increment. The test in set_user was wrong and the change to ucounts fixed it. So this fix only restores the old behavior in one lcation not two. Link: https://lkml.kernel.org/r/20220204181144.24462-1-mkoutny@suse.com Cc: stable@vger.kernel.org Reported-by: Michal Koutn=C3=BD Reviewed-by: Michal Koutn=C3=BD Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Signed-off-by: "Eric W. Biederman" --- kernel/fork.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index d75a528f7b21..17d8a8c85e3b 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2021,18 +2021,18 @@ static __latent_entropy struct task_struct *copy_pr= ocess( #ifdef CONFIG_PROVE_LOCKING DEBUG_LOCKS_WARN_ON(!p->softirqs_enabled); #endif + retval =3D copy_creds(p, clone_flags); + if (retval < 0) + goto bad_fork_free; + retval =3D -EAGAIN; if (is_ucounts_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLI= MIT_NPROC))) { if (p->real_cred->user !=3D INIT_USER && !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) - goto bad_fork_free; + goto bad_fork_cleanup_count; } current->flags &=3D ~PF_NPROC_EXCEEDED; =20 - retval =3D copy_creds(p, clone_flags); - if (retval < 0) - goto bad_fork_free; - /* * If multiple threads are within copy_process(), then this check * triggers too late. This doesn't hurt, the check is only there --=20 2.29.2 From nobody Sun Jun 28 01:49:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7ED0C433EF for ; Wed, 16 Feb 2022 15:59:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235855AbiBPP7h (ORCPT ); Wed, 16 Feb 2022 10:59:37 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232290AbiBPP72 (ORCPT ); Wed, 16 Feb 2022 10:59:28 -0500 Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D88862A7977; Wed, 16 Feb 2022 07:59:12 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:51956) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMhz-001oRf-8g; Wed, 16 Feb 2022 08:59:11 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37452 helo=localhost.localdomain) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMhy-002YPH-9D; Wed, 16 Feb 2022 08:59:10 -0700 From: "Eric W. Biederman" To: linux-kernel@vger.kernel.org Cc: Alexey Gladkov , Kees Cook , Shuah Khan , Christian Brauner , Solar Designer , Ran Xiaokai , containers@lists.linux-foundation.org, =?UTF-8?q?Michal=20Koutn=C3=BD?= , linux-api@vger.kernel.org, "Eric W. Biederman" , stable@vger.kernel.org Date: Wed, 16 Feb 2022 09:58:30 -0600 Message-Id: <20220216155832.680775-3-ebiederm@xmission.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> References: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1nKMhy-002YPH-9D;;;mid=<20220216155832.680775-3-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18QxC/y1NnTrInE0B67wHNJHnzhwk93cEs= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH v2 3/5] ucounts: Base set_cred_ucounts changes on the real user X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Koutn=C3=BD wrote: > Tasks are associated to multiple users at once. Historically and as per > setrlimit(2) RLIMIT_NPROC is enforce based on real user ID. > > The commit 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") > made the accounting structure "indexed" by euid and hence potentially > account tasks differently. > > The effective user ID may be different e.g. for setuid programs but > those are exec'd into already existing task (i.e. below limit), so > different accounting is moot. > > Some special setresuid(2) users may notice the difference, justifying > this fix. I looked at cred->ucount and it is only used for rlimit operations that were previously stored in cred->user. Making the fact cred->ucount can refer to a different user from cred->user a bug, affecting all uses of cred->ulimit not just RLIMIT_NPROC. Fix set_cred_ucounts to always use the real uid not the effective uid. Further simplify set_cred_ucounts by noticing that set_cred_ucounts somehow retained a draft version of the check to see if alloc_ucounts was needed that checks the new->user and new->user_ns against the current_real_cred(). Remove that draft version of the check. All that matters for setting the cred->ucounts are the user_ns and uid fields in the cred. Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220207121800.5079-4-mkoutny@suse.com Reported-by: Michal Koutn=C3=BD Reviewed-by: Michal Koutn=C3=BD Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Signed-off-by: "Eric W. Biederman" --- kernel/cred.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/kernel/cred.c b/kernel/cred.c index 473d17c431f3..933155c96922 100644 --- a/kernel/cred.c +++ b/kernel/cred.c @@ -665,21 +665,16 @@ EXPORT_SYMBOL(cred_fscmp); =20 int set_cred_ucounts(struct cred *new) { - struct task_struct *task =3D current; - const struct cred *old =3D task->real_cred; struct ucounts *new_ucounts, *old_ucounts =3D new->ucounts; =20 - if (new->user =3D=3D old->user && new->user_ns =3D=3D old->user_ns) - return 0; - /* * This optimization is needed because alloc_ucounts() uses locks * for table lookups. */ - if (old_ucounts->ns =3D=3D new->user_ns && uid_eq(old_ucounts->uid, new->= euid)) + if (old_ucounts->ns =3D=3D new->user_ns && uid_eq(old_ucounts->uid, new->= uid)) return 0; =20 - if (!(new_ucounts =3D alloc_ucounts(new->user_ns, new->euid))) + if (!(new_ucounts =3D alloc_ucounts(new->user_ns, new->uid))) return -EAGAIN; =20 new->ucounts =3D new_ucounts; --=20 2.29.2 From nobody Sun Jun 28 01:49:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68F2DC433EF for ; Wed, 16 Feb 2022 15:59:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235875AbiBPP7l (ORCPT ); Wed, 16 Feb 2022 10:59:41 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235834AbiBPP73 (ORCPT ); Wed, 16 Feb 2022 10:59:29 -0500 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE56C2A797D; Wed, 16 Feb 2022 07:59:14 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:58018) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMi2-009INN-4C; Wed, 16 Feb 2022 08:59:14 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37452 helo=localhost.localdomain) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMi0-002YPH-Jr; Wed, 16 Feb 2022 08:59:13 -0700 From: "Eric W. Biederman" To: linux-kernel@vger.kernel.org Cc: Alexey Gladkov , Kees Cook , Shuah Khan , Christian Brauner , Solar Designer , Ran Xiaokai , containers@lists.linux-foundation.org, =?UTF-8?q?Michal=20Koutn=C3=BD?= , linux-api@vger.kernel.org, "Eric W. Biederman" , stable@vger.kernel.org Date: Wed, 16 Feb 2022 09:58:31 -0600 Message-Id: <20220216155832.680775-4-ebiederm@xmission.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> References: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1nKMi0-002YPH-Jr;;;mid=<20220216155832.680775-4-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+ooX4vhp2sZhuHKwMTsjIRkVQYwVLWDik= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH v2 4/5] ucounts: Move RLIMIT_NPROC handling after set_user X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" During set*id() which cred->ucounts to charge the the current process to is not known until after set_cred_ucounts. So move the RLIMIT_NPROC checking into a new helper flag_nproc_exceeded and call flag_nproc_exceeded after set_cred_ucounts. This is very much an arbitrary subset of the places where we currently change the RLIMIT_NPROC accounting, designed to preserve the existing logic. Fixing the existing logic will be the subject of another series of changes. Cc: stable@vger.kernel.org Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Signed-off-by: "Eric W. Biederman" --- kernel/sys.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/kernel/sys.c b/kernel/sys.c index 8dd938a3d2bf..97dc9e5d6bf9 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -472,6 +472,16 @@ static int set_user(struct cred *new) if (!new_user) return -EAGAIN; =20 + free_uid(new->user); + new->user =3D new_user; + return 0; +} + +static void flag_nproc_exceeded(struct cred *new) +{ + if (new->ucounts =3D=3D current_ucounts()) + return; + /* * We don't fail in case of NPROC limit excess here because too many * poorly written programs don't check set*uid() return code, assuming @@ -480,14 +490,10 @@ static int set_user(struct cred *new) * failure to the execve() stage. */ if (is_ucounts_overlimit(new->ucounts, UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT= _NPROC)) && - new_user !=3D INIT_USER) + new->user !=3D INIT_USER) current->flags |=3D PF_NPROC_EXCEEDED; else current->flags &=3D ~PF_NPROC_EXCEEDED; - - free_uid(new->user); - new->user =3D new_user; - return 0; } =20 /* @@ -562,6 +568,7 @@ long __sys_setreuid(uid_t ruid, uid_t euid) if (retval < 0) goto error; =20 + flag_nproc_exceeded(new); return commit_creds(new); =20 error: @@ -624,6 +631,7 @@ long __sys_setuid(uid_t uid) if (retval < 0) goto error; =20 + flag_nproc_exceeded(new); return commit_creds(new); =20 error: @@ -703,6 +711,7 @@ long __sys_setresuid(uid_t ruid, uid_t euid, uid_t suid) if (retval < 0) goto error; =20 + flag_nproc_exceeded(new); return commit_creds(new); =20 error: --=20 2.29.2 From nobody Sun Jun 28 01:49:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C27AEC433F5 for ; Wed, 16 Feb 2022 15:59:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235876AbiBPP7m (ORCPT ); Wed, 16 Feb 2022 10:59:42 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235841AbiBPP7a (ORCPT ); Wed, 16 Feb 2022 10:59:30 -0500 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 012012A797F; Wed, 16 Feb 2022 07:59:17 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]:58066) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMi4-009INm-QR; Wed, 16 Feb 2022 08:59:16 -0700 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:37452 helo=localhost.localdomain) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nKMi3-002YPH-F4; Wed, 16 Feb 2022 08:59:16 -0700 From: "Eric W. Biederman" To: linux-kernel@vger.kernel.org Cc: Alexey Gladkov , Kees Cook , Shuah Khan , Christian Brauner , Solar Designer , Ran Xiaokai , containers@lists.linux-foundation.org, =?UTF-8?q?Michal=20Koutn=C3=BD?= , linux-api@vger.kernel.org, "Eric W. Biederman" , stable@vger.kernel.org Date: Wed, 16 Feb 2022 09:58:32 -0600 Message-Id: <20220216155832.680775-5-ebiederm@xmission.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> References: <87ilteiz4a.fsf_-_@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1nKMi3-002YPH-F4;;;mid=<20220216155832.680775-5-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/+Ki8jT8CUWv1olHpIGtHW6IqQTF2AmAU= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH v2 5/5] ucounts: Handle wrapping in is_ucounts_overlimit X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" While examining is_ucounts_overlimit and reading the various messages I realized that is_ucounts_overlimit fails to deal with counts that may have wrapped. Being wrapped should be a transitory state for counts and they should never be wrapped for long, but it can happen so handle it. Cc: stable@vger.kernel.org Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Signed-off-by: "Eric W. Biederman" Reviewed-by: Shuah Khan --- kernel/ucount.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/ucount.c b/kernel/ucount.c index 65b597431c86..06ea04d44685 100644 --- a/kernel/ucount.c +++ b/kernel/ucount.c @@ -350,7 +350,8 @@ bool is_ucounts_overlimit(struct ucounts *ucounts, enum= ucount_type type, unsign if (rlimit > LONG_MAX) max =3D LONG_MAX; for (iter =3D ucounts; iter; iter =3D iter->ns->ucounts) { - if (get_ucounts_value(iter, type) > max) + long val =3D get_ucounts_value(iter, type); + if (val < 0 || val > max) return true; max =3D READ_ONCE(iter->ns->ucount_max[type]); } --=20 2.29.2