]> git.baikalelectronics.ru Git - kernel.git/commit
ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1
authorEric W. Biederman <ebiederm@xmission.com>
Thu, 10 Feb 2022 02:03:19 +0000 (20:03 -0600)
committerEric W. Biederman <ebiederm@xmission.com>
Thu, 17 Feb 2022 15:10:33 +0000 (09:10 -0600)
commita946d5c437db059e379df4cbd7b24686b2ad7eec
tree89f629832dec4edfe14a82a78ac5b377871bbca7
parent33a547ab1a47d40b40790259fc087a94c6bcfc11
ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1

Michal Koutný <mkoutny@suse.com> 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 96a6f980d813 ("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
Link: https://lkml.kernel.org/r/20220216155832.680775-2-ebiederm@xmission.com
Cc: stable@vger.kernel.org
Reported-by: Michal Koutný <mkoutny@suse.com>
Reviewed-by: Michal Koutný <mkoutny@suse.com>
Fixes: 96a6f980d813 ("Reimplement RLIMIT_NPROC on top of ucounts")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
kernel/fork.c