Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp190307pxx; Wed, 28 Oct 2020 02:12:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKVfFm7jitA6qVkTjv/OKT5ACaH9LcM6a6EyR4KAjGDyk1jXkHRanwOVgEPSL8hmtr2BuF X-Received: by 2002:a05:6402:1245:: with SMTP id l5mr6982861edw.78.1603876366357; Wed, 28 Oct 2020 02:12:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603876366; cv=none; d=google.com; s=arc-20160816; b=I7nY2+NgrZKDx4Wjc9fEws1nhOJH2w4xzyOR6azeT4/b55vnVVoT/lp4g9e1XEsj2U JvjSH63F+fyQ8dq/5k4vyaMhBEbtfcWYmljenntBoZJO9CNIzrn2bFksRH6RWbDwUWyu 51kTlglSiyjhIwapv7HFkafPBGVnNcQd1lnPlZZOd+nHb+DUWHpAmDNhZyNH7uQX48sU CSpFjZwwbN9UCiC3N017hBvw8O37HygS/6gW+XxYVetTSYmQK/3dNlPY46od3tYpisvk o/MOE+sAkb8OEX8UW8p4KW+a9aUYUvqzyMTj17WlTfvNkpXVgNRQWRmRhqnFMdANymGr XWzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=+6lwA619svRo9d7HwCMYpxN1BMQFKB96PxDHZ3wbpew=; b=AQHfIzn6VXXnKr2tQThC78QU1fKauzUhYQOylkCTgp0WNgTzoyeqhHPmNjaFGo5W48 Px4Y8wb2QZ+YjiYPnikK5dsuZtYcWEphASUvoEgGr2GMS6jCO9RJmWitSozoKd6DsNNQ XYnW9bgr3tz66qfibKkeMQ0MQ5+eKooSNSdVP1D0kt4jRyZm0ogz4Hit+pztJUjr8Tyt pUOC/bKG/f+67VtxLQQe43LWRAeeDqJIZHHqPMoR7YduR9yKMfoTjWn0rTTss8swsZGJ PTB2ieP4WDJpLicQI9pO4Jj3xEOXOMVzv5XJQuT4GfXv2vwNaNqRGohBFbv6gIe40xdS hcMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Z5fRJwx0; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lg14si2653130ejb.82.2020.10.28.02.12.24; Wed, 28 Oct 2020 02:12:46 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=Z5fRJwx0; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756516AbgJ0OR0 (ORCPT + 99 others); Tue, 27 Oct 2020 10:17:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:35438 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756524AbgJ0ON4 (ORCPT ); Tue, 27 Oct 2020 10:13:56 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 38B9D2072D; Tue, 27 Oct 2020 14:13:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603808035; bh=QG/7ueEdEbsOxP7DxEbnpurwvC9xet4KgQ6y7mIGmCc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z5fRJwx0JPW3I8jMGJJOnqQmDC+vLkIaIzivDZ1MLvIS+i6Aks6Uf8gJhnNkiWbUp 4QcqP3X8nuDKjBZWl8Ci8vg3KTxIXSB68iD9M6Rbf9TjJC6ryf+C/sCIald0LFEpKF Cn8xZ6vJkcmB7F9z6ptzpl/mnLSGu3EeUnoZj0AM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vasant Hegde , Michael Ellerman , Sasha Levin Subject: [PATCH 4.14 131/191] powerpc/powernv/dump: Fix race while processing OPAL dump Date: Tue, 27 Oct 2020 14:49:46 +0100 Message-Id: <20201027134916.008149273@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027134909.701581493@linuxfoundation.org> References: <20201027134909.701581493@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vasant Hegde [ 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 --- arch/powerpc/platforms/powernv/opal-dump.c | 41 +++++++++++++++------- 1 file changed, 29 insertions(+), 12 deletions(-) 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) -- 2.25.1