From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx> commit 8f2f9c4d82f24f172ae439e5035fc1e0e4c229dd upstream. Michal Koutný <mkoutny@xxxxxxxx> 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@xxxxxxxx Link: https://lkml.kernel.org/r/20220216155832.680775-2-ebiederm@xxxxxxxxxxxx Cc: stable@xxxxxxxxxxxxxxx Reported-by: Michal Koutný <mkoutny@xxxxxxxx> Reviewed-by: Michal Koutný <mkoutny@xxxxxxxx> Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- kernel/fork.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2052,18 +2052,18 @@ static __latent_entropy struct task_stru #ifdef CONFIG_PROVE_LOCKING DEBUG_LOCKS_WARN_ON(!p->softirqs_enabled); #endif + retval = copy_creds(p, clone_flags); + if (retval < 0) + goto bad_fork_free; + retval = -EAGAIN; if (is_ucounts_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) { if (p->real_cred->user != INIT_USER && !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) - goto bad_fork_free; + goto bad_fork_cleanup_count; } current->flags &= ~PF_NPROC_EXCEEDED; - retval = 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 Patches currently in stable-queue which might be from ebiederm@xxxxxxxxxxxx are queue-5.16/ucounts-handle-wrapping-in-is_ucounts_overlimit.patch queue-5.16/ucounts-enforce-rlimit_nproc-not-rlimit_nproc-1.patch queue-5.16/ucounts-move-rlimit_nproc-handling-after-set_user.patch queue-5.16/ucounts-base-set_cred_ucounts-changes-on-the-real-user.patch queue-5.16/rlimit-fix-rlimit_nproc-enforcement-failure-caused-by-capability-calls-in-set_user.patch