Re: BUG: KASAN: use-after-free in dec_rlimit_ucounts

On Sun, Dec 19, 2021 at 11:58:41PM -0600, Eric W. Biederman wrote:

quoted

Qian Cai [off-list ref] writes:

quoted

On Wed, Nov 24, 2021 at 04:49:19PM -0500, Qian Cai wrote:

quoted

Hmm, I don't know if that or it is just this platfrom is lucky to trigger
the race condition quickly, but I can't reproduce it on x86 so far. I am
Cc'ing a few arm64 people to see if they have spot anything I might be
missing. The original bug report is here:

https://lore.kernel.org/lkml/YZV7Z+yXbsx9p3JN@fixkernel.com/ (local)

Okay, I am finally able to reproduce this on x86_64 with the latest
mainline as well by setting CONFIG_USER_NS and KASAN on the top of
defconfig (I did not realize it did not select CONFIG_USER_NS in the first
place). Anyway, it still took less than 5-minute by running:

$ trinity -C 48

It took me a while to get to the point of reproducing this but I can
confirm I see this with 2 core VM, running 5.16.0-rc4.

Running trinity 2019.06 packaged in debian 11.

I still can't reproduce :(

quoted

I didn't watch so I don't know if it was 5 minutes but I do know it took
less than an hour.

--- a/kernel/ucount.c
+++ b/kernel/ucount.c

@@ -209,6 +209,7 @@ void put_ucounts(struct ucounts *ucounts)

        if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) {
                hlist_del_init(&ucounts->node);
+               ucounts->ns = NULL;
                spin_unlock_irqrestore(&ucounts_lock, flags);
                kfree(ucounts);
        }

Does the previous hack increase the likelihood of an error being
triggered?