Linus, Please pull the ucount-rlimit-fixes-for-v5.17 branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git ucount-rlimit-fixes-for-v5.17 HEAD: 0cbae9e24fa7d6c6e9f828562f084da82217a0c5 ucounts: Handle wrapping in is_ucounts_overlimit Michal Koutný recently found some bugs in the enforcement of RLIMIT_NPROC in the recent ucount rlimit implementation. I saw some additional bugs and some cleaner ways to fix the problem so instead of starting with his fixes these are my own. I have rewritten about half my fixes since the last time this was posted. There is this notion (not entirely wrong) that the code should be consistent and make sense. When I dug in I discovered that has not been the case for the last 20 years. Fixing the long standing inconsistencies is something that seems to warrent wider vetting on linux-api. So with this set of patches I have developed a very conservative approach changing only what is necessary to fix the bugs that I can see clearly. Cleanups and anything that is making the code more consistent can follow after we have the code working as it has historically. I had hoped to let this sit in linux-next for a few days just to be doubly certain all is well. But these patches are all trivial and linux-next is on holiday. v2: https://lkml.kernel.org/r/87ilteiz4a.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> v1: https://lkml.kernel.org/r/87o83e2mbu.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> Eric W. Biederman (5): rlimit: Fix RLIMIT_NPROC enforcement failure caused by capability calls in set_user ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1 ucounts: Base set_cred_ucounts changes on the real user ucounts: Move RLIMIT_NPROC handling after set_user ucounts: Handle wrapping in is_ucounts_overlimit kernel/cred.c | 9 ++------- kernel/fork.c | 10 +++++----- kernel/sys.c | 20 ++++++++++++++------ kernel/ucount.c | 3 ++- 4 files changed, 23 insertions(+), 19 deletions(-) p.s. I should say that the problem is not so much inconsistencies (although those exist) but that it is very difficult to figure out what the code should be doing in the case of RLIMIT_NPROC. All other rlimits are only enforced where the resource is acquired (allocated). RLIMIT_NPROC by necessity needs to be enforced in an additional location, and our current implementation stumbled it's way into that implementation. Eric
