Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1134996pxb; Wed, 4 Nov 2020 00:30:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxHGEJ6wd3Ff0JMbHVaEx4RQ6ELawivUuFQJmZcTpUHjHuT30G2HjViZLQYoujSB7mNf1K/ X-Received: by 2002:a17:906:2b4e:: with SMTP id b14mr1867980ejg.354.1604478614852; Wed, 04 Nov 2020 00:30:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604478614; cv=none; d=google.com; s=arc-20160816; b=adFILYOFCmwH8EJq2onqIx+hxKkEZX/ZM08giIaFS0ucduNLL379LNGMokemxIIxYB aQ/c9veZ7jeIUczFgeGC4g0KIaYzpyMdSXf6dWKq+MpwHHrPYhpQbTi2F07R7DFhH+ss x8c1sCFyLRvJGoV5sIDA8hGPSHBu+f0APFcGa1S1Q7zjd2insD+E01it8Sxq2ZCXMWH7 cdtJ0jIVunoSyIaP2HxwaG0MmExNZbjULuDAd6u+sOGH1GUcuYNXjD4DCL79x0q1+z4X k+cIm8C2gvd6pvyrKGxc7B6BNuqD4rE+cDDStbAiDAhGsvZDaCZMhVecqhBAaDrY5zRO WrWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=jGe/qgYhnqg77yOrWZzm5L7l22XTJwlka6x2d/mIks0=; b=CHFlxQsyfkhc0aA5tcI7tT/IePgCNWzq8sWU8GteOP62Lxks+unHPYqog0dMgLXqhR UnUVFk+wIZJCSC2GbkAq7z4iI707BoBXMEWj2PV4GPcwMwChaMNAhhz/WzC+d+W1StHd yNdqkXWAVipQnTKxhqcTVa7cDoV7fHt7s9bdN6uO+1tEi8k2FoA+WuGppCuCwRpTEEa4 74n4TI101T0QhrnebT8a/Ygb+RmY42wD46IhOpI5jpQAJBqehBc+oGhLJBACJ4HhzEEt ZfYzM4dhjmuTNFlXDJ0BlpBYzFSI59wtt8MlfQvW9lpcd31c/mFxlFG9Cs8S8TW5Tisc YQEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bx3si1043562ejb.709.2020.11.04.00.29.50; Wed, 04 Nov 2020 00:30:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726690AbgKDI10 (ORCPT + 99 others); Wed, 4 Nov 2020 03:27:26 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:6743 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725812AbgKDI10 (ORCPT ); Wed, 4 Nov 2020 03:27:26 -0500 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4CR0Bb0VjJzkfH8; Wed, 4 Nov 2020 16:27:19 +0800 (CST) Received: from [10.174.179.106] (10.174.179.106) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.487.0; Wed, 4 Nov 2020 16:27:22 +0800 Subject: Re: Patch "powerpc/powernv/dump: Fix race while processing OPAL dump" has been added to the 4.4-stable tree To: , CC: References: <20201026055725.6F19F21BE5@mail.kernel.org> From: yangerkun Message-ID: <476bcc61-e59b-f3e5-e50b-44c65ee83a65@huawei.com> Date: Wed, 4 Nov 2020 16:27:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20201026055725.6F19F21BE5@mail.kernel.org> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.106] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, This will lead a compile error. arch/powerpc/platforms/powernv/opal-dump.c: In function ??process_dump??: arch/powerpc/platforms/powernv/opal-dump.c:409:7: error: void value not ignored as it ought to be dump = create_dump_obj(dump_id, dump_size, dump_type); ^ make[2]: *** [arch/powerpc/platforms/powernv/opal-dump.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [arch/powerpc/platforms/powernv] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [arch/powerpc/platforms] Error 2 make: *** Waiting for unfinished jobs.... ?? 2020/10/26 13:57, Sasha Levin ะด??: > This is a note to let you know that I've just added the patch titled > > powerpc/powernv/dump: Fix race while processing OPAL dump > > to the 4.4-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > powerpc-powernv-dump-fix-race-while-processing-opal-.patch > and it can be found in the queue-4.4 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let know about it. > > > > commit faa63b3cf39346b7a1e96d128133aadd8b59cc4a > Author: Vasant Hegde > Date: Sat Oct 17 22:12:10 2020 +0530 > > powerpc/powernv/dump: Fix race while processing OPAL dump > > [ Upstream commit 0a43ae3e2beb77e3481d812834d33abe270768ab ] > > Every dump reported by OPAL is exported to userspace through a sysfs > interface and notified using kobject_uevent(). The userspace daemon > (opal_errd) then reads the dump and acknowledges that the dump is > saved safely to disk. Once acknowledged the kernel removes the > respective sysfs file entry causing respective resources to be > released including kobject. > > However it's possible the userspace daemon may already be scanning > dump entries when a new sysfs dump entry is created by the kernel. > User daemon may read this new entry and ack it even before kernel can > notify userspace about it through kobject_uevent() call. If that > happens then we have a potential race between > dump_ack_store->kobject_put() and kobject_uevent which can lead to > use-after-free of a kernfs object resulting in a kernel crash. > > This patch fixes this race by protecting the sysfs file > creation/notification by holding a reference count on kobject until we > safely send kobject_uevent(). > > The function create_dump_obj() returns the dump object which if used > by caller function will end up in use-after-free problem again. > However, the return value of create_dump_obj() function isn't being > used today and there is no need as well. Hence change it to return > void to make this fix complete. > > Fixes: c7e64b9ce04a ("powerpc/powernv Platform dump interface") > Signed-off-by: Vasant Hegde > Signed-off-by: Michael Ellerman > Link: https://lore.kernel.org/r/20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com > Signed-off-by: Sasha Levin > > diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c > index 4c827826c05eb..e21e2c0af69d2 100644 > --- a/arch/powerpc/platforms/powernv/opal-dump.c > +++ b/arch/powerpc/platforms/powernv/opal-dump.c > @@ -319,15 +319,14 @@ static ssize_t dump_attr_read(struct file *filep, struct kobject *kobj, > return count; > } > > -static struct dump_obj *create_dump_obj(uint32_t id, size_t size, > - uint32_t type) > +static void create_dump_obj(uint32_t id, size_t size, uint32_t type) > { > struct dump_obj *dump; > int rc; > > dump = kzalloc(sizeof(*dump), GFP_KERNEL); > if (!dump) > - return NULL; > + return; > > dump->kobj.kset = dump_kset; > > @@ -347,21 +346,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size, > rc = kobject_add(&dump->kobj, NULL, "0x%x-0x%x", type, id); > if (rc) { > kobject_put(&dump->kobj); > - return NULL; > + return; > } > > + /* > + * As soon as the sysfs file for this dump is created/activated there is > + * a chance the opal_errd daemon (or any userspace) might read and > + * acknowledge the dump before kobject_uevent() is called. If that > + * happens then there is a potential race between > + * dump_ack_store->kobject_put() and kobject_uevent() which leads to a > + * use-after-free of a kernfs object resulting in a kernel crash. > + * > + * To avoid that, we need to take a reference on behalf of the bin file, > + * so that our reference remains valid while we call kobject_uevent(). > + * We then drop our reference before exiting the function, leaving the > + * bin file to drop the last reference (if it hasn't already). > + */ > + > + /* Take a reference for the bin file */ > + kobject_get(&dump->kobj); > rc = sysfs_create_bin_file(&dump->kobj, &dump->dump_attr); > - if (rc) { > + if (rc == 0) { > + kobject_uevent(&dump->kobj, KOBJ_ADD); > + > + pr_info("%s: New platform dump. ID = 0x%x Size %u\n", > + __func__, dump->id, dump->size); > + } else { > + /* Drop reference count taken for bin file */ > kobject_put(&dump->kobj); > - return NULL; > } > > - pr_info("%s: New platform dump. ID = 0x%x Size %u\n", > - __func__, dump->id, dump->size); > - > - kobject_uevent(&dump->kobj, KOBJ_ADD); > - > - return dump; > + /* Drop our reference */ > + kobject_put(&dump->kobj); > + return; > } > > static irqreturn_t process_dump(int irq, void *data) > . >