Received-SPF: pass (google.com: domain of linux-kernel+bounces-40243-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: <linux-kernel@vger.kernel.org>
CC: Rodrigo Vivi <rodrigo.vivi@intel.com>, Jose Souza <jose.souza@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Johannes Berg
	<johannes@sipsolutions.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>
Subject: [PATCH 1/2] devcoredump: Remove devcoredump device if failing device is gone
Date: Fri, 26 Jan 2024 10:11:19 -0500
Message-ID: <20240126151121.1076079-1-rodrigo.vivi@intel.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1A6pKNoecbTzhjdEkohxEgofuHzDaPbNBMQ+nkzlxTJhFY6LHzfONr3kPhIm?=
 =?us-ascii?Q?qR07t73L51WL+DAJk+tVgzZb185r9kvifACtrt9OvdWcA7HhVgHCBpFzAIQf?=
 =?us-ascii?Q?fTsu1eJpTawVbVgbwBfGL60zG4JW76jjV6jNo00EKk9Ma29vK2oAPX7fX+B/?=
 =?us-ascii?Q?S1ZQuaMajgYw0q9Yd5/qUesiMBuJ75Zj8bjoKzJNAF1DH5qWdY3JlJ7+SmJZ?=
 =?us-ascii?Q?TkVmi11XIBE3oyrHOoFDEzLgepaTvmrzEX0UDIrHq7DOdn6++uteyfi0Lcd6?=
 =?us-ascii?Q?COYUNDFlG+uBXbAV18q6aurSd7lYeRXKEnTUxEB0oY3dcj3ucw9kbTgjdiBm?=
 =?us-ascii?Q?qTIQ8JghI3M36k+ub6Gg6zh3kF3u858E4yzH3AdgXRPqKp+G293O2m4W4bK1?=
 =?us-ascii?Q?wdV9ooxEnj+KU4SkdA32NEe5SFDWYh+lwaTXRCIqpqlPpTyXOWXtpNM3VGi8?=
 =?us-ascii?Q?QKtESjEKslNG5QyQuJBWtEEXaGWISbpRmmFUhlkOZ3alny3bezLCQoXN0lzJ?=
 =?us-ascii?Q?oEzw+hAm8/vNsdsuEGIF0Ucg8JfSE+3+VwSm+EieSSV4kfgTI61bnl8tgP/p?=
 =?us-ascii?Q?bBD/cy9VGoW/QK3OsxRhDbKJhiBF1RdMvT8hDq/AGarTHuEjv29juTzk4rDH?=
 =?us-ascii?Q?jL3JdqU+xIvvIJ/ZAm908/jd82KB+rWuj69SVSz5Qu/Z2dxltbt8k+vVardU?=
 =?us-ascii?Q?sdH6V2aylMypcEKBNBFT0z6+QKecl+xi0Eq/xfBW2bnPSfrqs6wx3Zke44mp?=
 =?us-ascii?Q?Q/VgpwccwS/3mV1IMq4SnthgjTtTGr18v+n6plU/QbZr3w38/ebwcNVZfsIU?=
 =?us-ascii?Q?MOA3bwKIUcrt9BcCL1S+j7el3MSTsOiQsdPxAluISXTyJgsNCzPMWYDjAg1+?=
 =?us-ascii?Q?ekXEym8XIKt7n8329Hwkle1VaepTp6JE3rM4L2ohXEozKnjv+1OnMIAXc6KT?=
 =?us-ascii?Q?sEazxM7T5hROwqVRQ7gGA5L0BfG1ezs4zY4pxfPJncgllC/vrkrWi+brDcDP?=
 =?us-ascii?Q?Nt/HQwbUVVxx/QrP5CSQ1sjutZ518tBOA5MgXInThVKtXgvtYKRZ2kF+pgcR?=
 =?us-ascii?Q?230iMbruZD8voD9JoItazdQTvIPL40DkWCCs9Q1Ho081UZPsbAGIrbQzskC1?=
 =?us-ascii?Q?U4uNuYaEEyYgAhKmoE0odk6weYTtyjJA1TS8IItrEjCJ+36H5c8gyRgJazn6?=
 =?us-ascii?Q?X0Kdh5m/r/0S3J8b42hIqW6k9cPanFstskSR431fH9Nmvjh6/JDYKPKFGCBQ?=
 =?us-ascii?Q?9hNiUfWWx1LFTQNGwYgluO/PuI5ownHn3K7TsGkZFMWKMtwZupdFcxrK6pth?=
 =?us-ascii?Q?ysjzT6jbnvWhxQjljcuQIXPK/8rRc3/tXKbREWFeeeQuVfeJOqaGXLbkhJQb?=
 =?us-ascii?Q?qYD/idT4ROCcW5DM652jxjEweUr/OZZ0K34QUB7L3s+SqnQjeCqxMipGZEAt?=
 =?us-ascii?Q?qBigt+r/JMbxmq3Q1zkLvfOQDPzrCSfw1e03FyRDNt8NYCgFy/jE5fgv90+E?=
 =?us-ascii?Q?EUTWWVVj91IVYVR5IPymTIhq5HvxASAgi3T2hGUk+zl+V7d+lG1alt30hcZe?=
 =?us-ascii?Q?smiC/oukNQR2mgfv+YojJQrf2oxM1Y0yAVKF1qo7?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 480998c8-f282-4a7d-00a1-08dc1e81108b
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6059.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2024 15:11:25.9895
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: VHWjAfsftISKqi40v9XbjYFBkzp/jJhEcrHAxNs4YVsAcNj2cOG06xlv6AdXnIoJq4wa2lpVC99/K++h4X2RvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7873
X-OriginatorOrg: intel.com

Make dev_coredumpm a real device managed helper, that not only
frees the device after a scheduled delay (DEVCD_TIMEOUT), but
also when the failing/crashed device is gone.

The module remove for the drivers using devcoredump are currently
broken if attempted between the crash and the DEVCD_TIMEOUT, since
the symbolic sysfs link won't be deleted.

On top of that, for PCI devices, the unbind of the device will
call the pci .remove void function, that cannot fail. At that
time, our device is pretty much gone, but the read and free
functions are alive trough the devcoredump device and they
can get some NULL dereferences or use after free.

So, if the failing-device is gone let's also request for the
devcoredump-device removal using the same mod_delayed_work
as when writing anything through data. The flush cannot be
used since it is synchronous and the devcd would be surely
gone right before the mutex_unlock on the next line.

Cc: Jose Souza <jose.souza@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/base/devcoredump.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
index 7e2d1f0d903a..678ecc2fa242 100644
--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -304,6 +304,19 @@ static ssize_t devcd_read_from_sgtable(char *buffer, loff_t offset,
 				  offset);
 }
 
+static void devcd_remove(void *data)
+{
+	struct devcd_entry *devcd = data;
+
+	mutex_lock(&devcd->mutex);
+	if (!devcd->delete_work) {
+		devcd->delete_work = true;
+		/* XXX: Cannot flush otherwise the mutex below will hit a UAF */
+		mod_delayed_work(system_wq, &devcd->del_wk, 0);
+	}
+	mutex_unlock(&devcd->mutex);
+}
+
 /**
  * dev_coredumpm - create device coredump with read/free methods
  * @dev: the struct device for the crashed device
@@ -381,6 +394,8 @@ void dev_coredumpm(struct device *dev, struct module *owner,
 	kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD);
 	INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
 	schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
+	if (devm_add_action(dev, devcd_remove, devcd))
+		dev_warn(dev, "devcoredump managed auto-removal registration failed\n");
 	mutex_unlock(&devcd->mutex);
 	return;
  put_device:
-- 
2.43.0