linux-kernel - Re: [PATCH] signal: restore the override

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEWA0a4Kz9exk04Wgx9UZ9YFfURnS-=50TWyhPHm3i-N-D_8DA@mail.gmail.com>
Date: Fri, 1 Nov 2024 15:44:48 -0700
From: Andrei Vagin <avagin@...gle.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Roman Gushchin <roman.gushchin@...ux.dev>, linux-kernel@...r.kernel.org, 
	Kees Cook <kees@...nel.org>, Alexey Gladkov <legion@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH] signal: restore the override_rlimit logic

On Fri, Nov 1, 2024 at 1:58 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:

> > Well, personally I'd not use this limit too, but I don't think
> > "it's broken, userspace shouldn't use it" argument is valid.
>
> I said if you don't want the limit don't use it.
>
> A version of "Doctor it hurts when I do this". To which the doctor
> replies "Don't do that then".

Unfortunately, it isn't an option here. This is a non-root user that
creates a new user-namespace. It can't change RLIMIT_SIGPENDING
beyond the current limit.

We have to distinguish between two types of signals:

* Kernel signals: These are essential for proper application behavior.
If a user process triggers a memory fault, it gets SIGSEGV and it can’t
ignore it. The number of such signals is limited by one per user thread.

* User signals: These are sent by users and can be blocked by the
receiving process, potentially leading to a large queue of pending
signals. This is where the RLIMIT_SIGPENDING limit plays its role in
preventing excessive resource consumption.

New user namespaces inherit the current sigpending rlimit, so it is
expected that  the behavior of the user-namespace limit is aligned with
the overall RLIMIT_SIGPENDING mechanism.

>
> I was also asking that you test with the limit disabled (at user
> namespace creation time) so that you can verify that is problem.
>
> >> The maximum for rlimit(RLIM_SIGPENDING) is the rlimit(RLIM_SIGPENDING)
> >> value when the user namespace is created.
> >>
> >> Given that it took 3 and half years to report this.  I am going to
> >> say this really looks like a userspace bug.

This issue was introduced in  v5.15. The latest rhel release, 9.4, is
based on v5.14...
3.5 years is not a long time...

Thanks,
Andrei