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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 859A0C433DB for ; Thu, 28 Jan 2021 11:39:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED40E64DDA for ; Thu, 28 Jan 2021 11:39:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED40E64DDA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 59BEB6B0072; Thu, 28 Jan 2021 06:39:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54B046B0074; Thu, 28 Jan 2021 06:39:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46B2B6B0075; Thu, 28 Jan 2021 06:39:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 31CBC6B0072 for ; Thu, 28 Jan 2021 06:39:25 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E063B3623 for ; Thu, 28 Jan 2021 11:39:24 +0000 (UTC) X-FDA: 77754988248.02.cook38_12092e12759f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id C5BBA10097AA1 for ; Thu, 28 Jan 2021 11:39:24 +0000 (UTC) X-HE-Tag: cook38_12092e12759f X-Filterd-Recvd-Size: 4086 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Jan 2021 11:39:23 +0000 (UTC) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DRJP26h74zl9l6; Thu, 28 Jan 2021 19:37:42 +0800 (CST) Received: from [10.174.179.81] (10.174.179.81) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Thu, 28 Jan 2021 19:39:12 +0800 Subject: Re: KASAN: invalid-free in p9_client_create (2) To: Linus Torvalds , syzbot , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton CC: Dominique Martinet , David Miller , , Jakub Kicinski , Linux Kernel Mailing List , , Netdev , syzkaller-bugs , , Linux-MM References: <000000000000672eda05b9e291ff@google.com> From: "wanghai (M)" Message-ID: Date: Thu, 28 Jan 2021 19:39:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [10.174.179.81] X-CFilter-Loop: Reflected Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: =E5=9C=A8 2021/1/28 3:31, Linus Torvalds =E5=86=99=E9=81=93: > [ Participants list changed - syzbot thought this was networking and > p9, but it really looks entirely like a slub internal bug. I left the > innocent people on the list just to let them know they are innocent ] > > On Wed, Jan 27, 2021 at 6:27 AM syzbot > wrote: >> The issue was bisected to: >> >> commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2 >> Author: Wang Hai >> Date: Wed Jun 3 22:56:21 2020 +0000 >> >> mm/slub: fix a memory leak in sysfs_slab_add() >> >> BUG: KASAN: double-free or invalid-free in slab_free mm/slub.c:3142 [i= nline] >> BUG: KASAN: double-free or invalid-free in kmem_cache_free+0x82/0x350 = mm/slub.c:3158 > The p9 part of this bug report seems to be a red herring. > > The problem looks like it's simply the kmem_cache failure case, ie: > > - mm/slab_common.c: create_cache(): if the __kmem_cache_create() > fails, it does: > > out_free_cache: > kmem_cache_free(kmem_cache, s); > > - but __kmem_cache_create() - at least for slub() - will have done > > sysfs_slab_add(s) .. fails .. > -> kobject_del(&s->kobj); .. which frees s ... > > so the networking and p9 are fine, and the only reason p9 shows up in > the trace is that apparently it causes that failure in > kobject_init_and_add() for whatever reason, and that then exposes the > problem. > > So the added kobject_put() really looks buggy in this situation, and > the memory leak that that commit dde3c6b72a16 ("mm/slub: fix a memory > leak in sysfs_slab_add()") fixes is now a double free. > > And no, I don't think you can just remove the kmem_cache_free() in > create_cache(), because _other_ error cases of __kmem_cache_create() > do not free this. > > Wang Hai - comments? I'm inclined to revert that commit for now unless > somebody can come up with a proper fix.. > > Linus > . Hi, Linus. I'm sorry for introducing this bug, and I agree to revert it. I've just sent the revert patch. https://lore.kernel.org/patchwork/patch/1372475/ Thanks, Wang Hai