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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79CDBC433F5 for ; Thu, 18 Nov 2021 19:46:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5AF2861A52 for ; Thu, 18 Nov 2021 19:46:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233375AbhKRTtQ (ORCPT ); Thu, 18 Nov 2021 14:49:16 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:42156 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232804AbhKRTtO (ORCPT ); Thu, 18 Nov 2021 14:49:14 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]:45014) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mnnML-000oY8-MV; Thu, 18 Nov 2021 12:46:13 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:48772 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 1mnnMK-003oBG-Co; Thu, 18 Nov 2021 12:46:13 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Qian Cai Cc: Alexey Gladkov , Yu Zhao , References: Date: Thu, 18 Nov 2021 13:46:05 -0600 In-Reply-To: (Qian Cai's message of "Wed, 17 Nov 2021 17:00:07 -0500") Message-ID: <875ysptfgi.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=1mnnMK-003oBG-Co;;;mid=<875ysptfgi.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/TnzlgEA7YGDyydVrGjr/zPCC+vAMjgt0= X-SA-Exim-Connect-IP: 68.227.160.95 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 Qian Cai writes: > Hi there, I can still reproduce this quickly on today's linux-next and all > the way back to 5.15-rc6 by running a syscall fuzzer for a while. The trace > points out to this line, > > for (iter = ucounts; iter; iter = iter->ns->ucounts) { > > It looks KASAN indicated that that "ns" had already been freed. Is that > possible or perhaps this is more of refcount issue? Is it possible? Yes it is possible. That is one place where a use-after-free has shown up and I expect would show up in the future. That said it is hard to believe there is still a user-after-free in the code. We spent the last kernel development cycle pouring through and correcting everything we saw until we ultimately found one very subtle use-after-free. If you have a reliable reproducer that you can share, we can look into this and see if we can track down where the reference count is going bad. It tends to take instrumenting the entire life cycle every increment and every decrement and then pouring through the logs to track down a use-after-free. Which is not something we can really do without a reproducer. Eric