From nobody Sun May 24 22:36:43 2026 Received: from mail-pg1-f227.google.com (mail-pg1-f227.google.com [209.85.215.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF29237B01F for ; Wed, 20 May 2026 21:13:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.227 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779311591; cv=none; b=HmbiAqREwg1hrCGkx4roHYSrwcwOf/X0adKbHXh9QOAJ4pCZw57kRlgp42kdpMYudkymNf6Ru5fDJvh4UCUOnfIte9QpkOWduCj117P5/p1ERxr9qd//R45PmDT2eMD3fXvPC0yzb4GOJxK8XogNh6hnubXBPzVAVQUWfkt9AzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779311591; c=relaxed/simple; bh=g3XqxIZVAtiYRCC/Ha11lGANX3W39mRhS+q9W0tVlGQ=; h=From:To:Cc:Subject:Date:Message-ID; b=G2IkCVRmEZCzO5A26Jlccqjq/0tvcOFAXgg6XhYvfTlb503IMUrPb49QR6Z4LTkvQuxw+zkWhWEt2GUissbzcnqtrLB5zQ2m5byqaP6xZU+G1TzyDKcdHu8gdXtoo+0yzQT8FkoDkp7gwGE7wjIwcXBiARZdTGjPS92k7/xAoII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arista.com; spf=pass smtp.mailfrom=arista.com; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b=fSJ89dqD; arc=none smtp.client-ip=209.85.215.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arista.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arista.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b="fSJ89dqD" Received: by mail-pg1-f227.google.com with SMTP id 41be03b00d2f7-c796163fac5so4545077a12.1 for ; Wed, 20 May 2026 14:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779311588; x=1779916388; h=content-transfer-encoding:message-id:date:subject:cc:to:from :dkim-signature:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=csEWhLBeuXUIcPbnmNvH2qpT5Hb/mVQdn2helAHeEmE=; b=Jd56dgGHhwzyrprg7he729HSEVA2/DEa6+710aRc/CLUJg6ZR78spsyw15EF8nMhrZ izzoIERqGGE13vcZ4vQ0mFl8VCXASzYQtCsHYSa3mkqzld8WvtzCyK0rbe1V9u0w30+8 OFhf5+EMB1kphqruc7dZoHvXsQr6ljJTSnm2TkrTacuMON4hT5HfkLnw11KDM2cTqsSF DiwyJodTeBmwpxPebd0B/q1nQQRpTyOR/mP1d69/Y341Wd17REN1krQ3bz/dYODD/8Py 4tpitQgUTsPwQClD1B9PkWKZLAAKEbcsMinlRY2qdHdS8A6y3H7ZVK0TNfx8fHXsobWN 5e9Q== X-Forwarded-Encrypted: i=1; AFNElJ/EB3OtMD9hl5zoObnMnxHHRS5fAwJL/9/zKFtMAWPkSyHMcUCa9vuKSYeNTW4Hai4xUJD2iPaI/ILTG74=@vger.kernel.org X-Gm-Message-State: AOJu0Yws/YvMqpr/LTifyf0UKszyBUk6Rv7gnY9XnUPef2zOwu+OsGZq yRiSaP3G7bZWq88C4JMnRw5GTkGW7gXwj4mJjKEx6qalelxG0vINddPyuUx0zw5OY7Am28LPWtq 9x53tj46BJJGIrVassNoFi1eDiWyYpS55VQ== X-Gm-Gg: Acq92OEZm66bwLkrFAroKvyWb3IB4mg/HST1EzKc98S/Py/iPMYxaQRSL7vgQaW/1x+ pzaMEcGJ8F9O2UXE9kMHfZKkzGRYx56fuvMPLyHfuY+z5rvSXk3PFQ0yQbjKuF6RmM5UZQvhG5j 42RtB0mQfH/6HpFsL9OykCRYrc+3jtuTr9M4h//ODEs+ruwkygmREjz8jzvjK4s7QaL+eza0ZQc a1GrvRH4kelKgVfBwuatRWbS4wuH0ARHyxkJqZyZkTTfXvUNLYti465Ft3UWIdkGrsugrBJyw3F Snc0aQuxRsCzhqZmluUEPvKQR2MaA4CLbxCbXaPJNfmLW/Z4CYrwGS4ojS1DNCQ7+lbamVO6ipB 4Hcj8VnRZO3F8i3kxUCoqIJR8iZH4u7crbuLWJz1wQq352wE3E8RRLlgBbaLp0WyVqIenSKa8x1 FqkZCHT7zF8HXtcxu364LI91Mm/+r6oXKlYA== X-Received: by 2002:a17:903:22c3:b0:2b0:52b7:e82 with SMTP id d9443c01a7336-2bd7e7ef8d9mr288288395ad.16.1779311587845; Wed, 20 May 2026 14:13:07 -0700 (PDT) Received: from smtp.aristanetworks.com (ec2-52-52-135-65.us-west-1.compute.amazonaws.com. [52.52.135.65]) by smtp-relay.gmail.com with ESMTPS id d9443c01a7336-2bd5bd696a0sm16431335ad.9.2026.05.20.14.13.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 14:13:07 -0700 (PDT) X-Relaying-Domain: arista.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=Arista-A; t=1779311586; bh=csEWhLBeuXUIcPbnmNvH2qpT5Hb/mVQdn2helAHeEmE=; h=From:To:Cc:Subject:Date:From; b=fSJ89dqD5XhJiv8ZMsb+ggFP9uqIHbgJKba86vK22Lf3822LHygIoxovj/+r4Tiq3 /assuztVFA3Qg4eGt3Dj1YP3fj+TkKCHBYAPJFztNCqDFSPlwgfqAX6rFewp3B3J2M WsvWkOnIZe4QpxQFGc9LD7jmJuwWPFb69+7LENu7tKrGyv8LxpLczHpAQY+ZE9seI4 wkF/qOPVEkYJAnQS6096ABlmPrAlCIbW8JSzQgGiAw8Y4ryFBN0kDk0Q+psKlsYKaB /OhOOlUtk/YzHjpcott1zEeXjGuF9V8LTfXq1E2BlGls9R5UzY4cMQ8ll55oLqssk+ r6TMabOO6bIbA== Received: from gianfranco-dutka-usb-uas.sjc.aristanetworks.com (dhcp-224-35-225.sjc.aristanetworks.com [10.224.35.225]) by smtp.aristanetworks.com (Postfix) with ESMTP id 90B67C2B2B; Wed, 20 May 2026 21:13:06 +0000 (UTC) X-SMTP-Authentication: Allow-List-permitted X-SMTP-Authentication: Allow-List-permitted From: Gianfranco Dutka To: Bjorn Helgaas Cc: Gianfranco Dutka , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] PCI/sysfs: NULL res_attr slot after kfree as defence against double-remove Date: Wed, 20 May 2026 14:13:06 -0700 Message-ID: <20260520211306.3301893-1-gianfranco.dutka@arista.com> Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" pci_remove_resource_files() frees the bin_attribute pointed at by pdev->res_attr[i] / pdev->res_attr_wc[i] but does not clear the slot after kfree(). If pci_remove_sysfs_dev_files() is ever invoked twice against the same pdev, the second pass dereferences a freed bin_attribute and faults inside strlen() called from kernfs_remove_by_name_ns(). To the best of my knowledge no in-tree caller hits this today -- the primary path (pci_stop_dev() -> pci_remove_sysfs_dev_files()) is expected to fire once per device -- so this is being submitted as defence-in-depth rather than as a fix for a reproducer in the upstream tree. The motivation is that a freed-but-not-cleared pointer in a device-lifetime table is a sharp edge: any future caller (in-tree or out-of-tree) that re-enters the teardown path turns it into a UAF with no warning. Other allocator-managed pointer tables in the kernel NULL the slot after kfree() for exactly this reason, and the two-line change makes pci_remove_resource_files() idempotent at essentially zero cost. For full disclosure: the way I encountered this was via an out-of-tree PCIe hotplug driver on an AMD Ryzen Embedded V3000 platform. The driver re-enters pci_stop_and_remove_bus_device() against a pdev that the standard pci_destroy_dev() path has already torn down, and with slub_debug=3DFZPU the second entry faults with the classic POISON_FREE signature: BUG: unable to handle page fault for address: 6b6b6b6b6b6b6b6b RIP: strlen+0x4 Call Trace: kernfs_find_ns kernfs_remove_by_name_ns sysfs_remove_bin_file pci_remove_resource_files pci_remove_sysfs_dev_files pci_stop_bus_device pci_stop_and_remove_bus_device I am aware that "out-of-tree driver re-enters teardown" is not by itself a reason to take a change upstream, and I would understand a NACK on that basis. The reason I am still sending it is that the fix is local, mechanical, matches an idiom already used elsewhere in the kernel, and removes a class of bug rather than papering over the specific caller that surfaced it. Signed-off-by: Gianfranco Dutka --- drivers/pci/pci-sysfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -1228,11 +1228,13 @@ static void pci_remove_resource_files(struct pci_de= v *pdev) if (res_attr) { sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); kfree(res_attr); + pdev->res_attr[i] =3D NULL; } res_attr =3D pdev->res_attr_wc[i]; if (res_attr) { sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); kfree(res_attr); + pdev->res_attr_wc[i] =3D NULL; } } } -- 2.43.0