linux-kernel - Re: [CFT][PATCH] ucounts: Fix signal ucount refcounting

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]

Date:   Sun, 17 Oct 2021 18:47:27 +0200
From:   Rune Kleveland <rune.kleveland@...omedia.dk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Yu Zhao <yuzhao@...gle.com>, Alexey Gladkov <legion@...nel.org>,
        Jordan Glover <Golden_Miller83@...tonmail.ch>,
        LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        containers@...ts.linux-foundation.org
Subject: Re: [CFT][PATCH] ucounts: Fix signal ucount refcounting

Hi!

After applying the below patch, the 5 most problematic servers have run 
without any issues for 23 hours. That never happened before the patch on 
5.14, so the patch seems to have fixed the issue for me.

On Monday there will be more load on the servers, which caused them to 
crash faster without the patch. I will let you know if it happens again.

Best regards,
Rune

On 16/10/2021 00:10, Eric W. Biederman wrote:
> 
> In commit fda31c50292a ("signal: avoid double atomic counter
> increments for user accounting") Linus made a clever optimization to
> how rlimits and the struct user_struct.  Unfortunately that
> optimization does not work in the obvious way when moved to nested
> rlimits.  The problem is that the last decrement of the per user
> namespace per user sigpending counter might also be the last decrement
> of the sigpending counter in the parent user namespace as well.  Which
> means that simply freeing the leaf ucount in __free_sigqueue is not
> enough.
> 
> Maintain the optimization and handle the tricky cases by introducing
> inc_rlimit_get_ucounts and dec_rlimit_put_ucounts.
> 
> By moving the entire optimization into functions that perform all of
> the work it becomes possible to ensure that every level is handled
> properly.
> 
> I wish we had a single user across all of the threads whose rlimit
> could be charged so we did not need this complexity.