From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 364A5C433EF for ; Mon, 27 Dec 2021 15:24:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237328AbhL0PW4 (ORCPT ); Mon, 27 Dec 2021 10:22:56 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:46624 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230158AbhL0PWz (ORCPT ); Mon, 27 Dec 2021 10:22:55 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]:57768) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1n1rpu-00EZTE-Bn; Mon, 27 Dec 2021 08:22:54 -0700 Received: from ip68-110-24-146.om.om.cox.net ([68.110.24.146]:53952 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1n1rpt-000RLD-2o; Mon, 27 Dec 2021 08:22:53 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Alexey Gladkov Cc: Qian Cai , Yu Zhao , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org References: <875ysptfgi.fsf@email.froward.int.ebiederm.org> <87k0h5rxle.fsf@email.froward.int.ebiederm.org> <8735mnakby.fsf@email.froward.int.ebiederm.org> <20211221130937.yokn25stgjpzax7n@example.org> Date: Mon, 27 Dec 2021 09:22:20 -0600 In-Reply-To: <20211221130937.yokn25stgjpzax7n@example.org> (Alexey Gladkov's message of "Tue, 21 Dec 2021 14:09:37 +0100") Message-ID: <87zgomrs2b.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1n1rpt-000RLD-2o;;;mid=<87zgomrs2b.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.110.24.146;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+eeZnfb1D1Jnm9EjwwOXbfxGZEXvWZ6DQ= X-SA-Exim-Connect-IP: 68.110.24.146 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: BUG: KASAN: use-after-free in dec_rlimit_ucounts X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alexey Gladkov writes: > On Sun, Dec 19, 2021 at 11:58:41PM -0600, Eric W. Biederman wrote: >> Qian Cai writes: >> >> > On Wed, Nov 24, 2021 at 04:49:19PM -0500, Qian Cai wrote: >> >> 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/ >> > >> > 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 :( > >> 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? It doesn't seem to make a difference. That makes sense as the kernel address sanitizer is part of the kernel configuration required to reproduce the issue. Eric