From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793831497; b=YmDLLFzbbadgTdg0QrLnRCKUG+8aNijPpf/DEtcPactwrFWgeVWTbbgHqvI3qm7qjqW7 mltiCjcQfrHYTYbeavlRWCDbT6vH4pDHg+0BRI+39OsDIYBvi2azgRi0JWTu7W+yMAutB 42dTLpCwMkgeYTKgr/OExcWCxFd9FfJ6nUjQqZmM1kgu0jCPqqt0wzywj9APjWHZMHcj9 wVqFoeJjT0GgTjFSMHDzF4vxV0ltCTIpTl9KA+RX9ctWO+P1vL5M6GEhXW1wbB8FUXB3i MHG4afef3zJd1VJeR3RH9wkF+xLuYFTk9lypCLYuz1GeQOf1mR8mFZiBMlZD0HnqfRA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793831497; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=NlWLVhj/ohlBx/eF3gW17Q1fqM/HUc/resMPw8CZsnA=; b=fepGX8OsIUUtXh0DjunDv4eWyNTx0RxhB4oupzCq6rN4241deMmKPo4YFXN+LPGrIwzs LcS97Gmqp2QfrOGiyatBpsUiDjxUgstfW4d14kum4ZBbC/9WMJXQ/bS7gtgyq2HzcKZE4 B0JMNPn2NEBbiibUMrEjeoNrxgdxUkk3T9FXeS0qHzeKA9rP3qjDEr0ZmMGdCsBGH9nRv 3HgNOiSsLiHbYfpeGW/DmPLyhLRjcF1fFEfyZr46J7QwGeXCZp6VxzrPKwmIuy/n1WpEs QKIyt1e2og8RKM3iAVNx/eozDdpsbycGBW7pvMjaDpmSp+NO/CAYXIZ5lsGvjEQ1rkg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="FFR/vqdd"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 959F6606B3B7; Wed, 4 Nov 2026 22:31:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=FFR/vqdd Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39B3D1F00A17; Wed, 4 Nov 2026 22:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793831497; bh=NlWLVhj/ohlBx/eF3gW17Q1fqM/HUc/resMPw8CZsnA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FFR/vqddTdNdL2lhx0m5fQ/8MEuwwkbISv5FMk48I2a8o3KWJKucW2ZnMnjzL61w+ OjxjIlvF0Hbapo6N7axp4x01BEt1IrrQSNBAllyTeyV/2tVtSzJOfzkzGQGIWV3dvr N0w/y5FDIGU+6YGyCX50V+i2fP6PUjRw7DKFXPn0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Nickolai Zeldovich , Andrew Morton , Tejun Heo , Bradley Morgan , Bjorn Helgaas , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Thierry Reding Subject: [PATCH 6.18 0739/1005] resource: report a devm_request_resource() conflict under the lock Date: Wed, 4 Nov 2026 16:07:52 -0500 Message-ID: <20261104211104.179129874@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nickolai Zeldovich commit d2f7bdfdeac8137e942b32e0badc40e181127d7b upstream. devm_request_resource() calls request_resource_conflict(), which takes resource_lock, tries to insert the new resource and returns a pointer to the conflicting resource after dropping the lock. The error message is then formatted from that pointer: conflict->name and the %pR argument read the name, start, end, flags and desc of a resource that nothing pins any more. The owner of the conflicting resource may call release_resource() and free it the moment the lock is dropped. The conflicting resource normally belongs to another device. With two devices whose drivers claim overlapping regions (two PCI host bridges whose "ranges" windows overlap, two instances of a controller on the same aperture, or a stale claim an administrator is replacing), the following interleaving reads freed memory: CPU 0: driver B probe CPU 1: driver A unbind devm_request_resource(devB, root, resB) request_resource_conflict() write_lock(&resource_lock) __request_resource() -> resA write_unlock(&resource_lock) devres_release_all(devA) devm_resource_release() release_resource(resA) put_device() -> kfree(resA) dev_err(..., resA->name, resA) use after free Both halves are reachable from userspace on any kernel: a write to the "unbind" file of the driver that holds the region and a write to the "bind" file of the driver that wants it. One in-tree path is drivers/pci/bus.c devm_request_pci_bus_resources(), called from host bridge probe for every bridge window; the windows are the embedded struct resource of kzalloc'ed resource_entry objects that pci_free_resource_list() frees when the other bridge is released. In the common case the "resource collision" message is garbled; with the slab object poisoned (CONFIG_SLUB_DEBUG) or reused, formatting conflict->name oopses, and KASAN reports a slab-use-after-free read in devm_request_resource(). All of this happens in a probe that is already failing with -EBUSY. The window is a few hundred instructions wide and exists only when two devices actually collide, so the race has not been observed outside of analysis. Do the same here: take resource_lock, insert with __request_resource() and print the diagnostic while the lock still keeps the conflicting resource in the tree, then drop the lock. The return values and the devres handling are unchanged. The change was built for x86_64 and RISC-V; the resource KUnit tests pass on both. Found by formal verification of kernel/resource.c against the kernel binary. Link: https://lore.kernel.org/20261016140043.790048-1-nickolai@csail.mit.edu Fixes: 8d38821cbcf5 ("resources: Add device-managed request/release_resource()") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Acked-by: Tejun Heo Reviewed-by: Bradley Morgan Assisted-by: LLM Cc: Bjorn Helgaas Cc: Ilpo Järvinen Cc: Thierry Reding Cc: Signed-off-by: Greg Kroah-Hartman --- kernel/resource.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1645,10 +1645,15 @@ int devm_request_resource(struct device *ptr = new; - conflict = request_resource_conflict(root, new); - if (conflict) { + /* Report a conflict while the lock still keeps it in the tree. */ + write_lock(&resource_lock); + conflict = __request_resource(root, new); + if (conflict) dev_err(dev, "resource collision: %pR conflicts with %s %pR\n", new, conflict->name, conflict); + write_unlock(&resource_lock); + + if (conflict) { devres_free(ptr); return -EBUSY; }