* + resource-report-a-devm_request_resource-conflict-under-the-lock.patch added to mm-unstable branch
@ 2026-10-17 2:18 Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2026-10-17 2:18 UTC (permalink / raw)
To: mm-commits, treding, tj, ilpo.jarvinen, brads, bhelgaas, nickolai,
akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5453 bytes --]
The patch titled
Subject: resource: report a devm_request_resource() conflict under the lock
has been added to the -mm mm-unstable branch. Its filename is
resource-report-a-devm_request_resource-conflict-under-the-lock.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/resource-report-a-devm_request_resource-conflict-under-the-lock.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
Subject: resource: report a devm_request_resource() conflict under the lock
Date: Fri, 16 Oct 2026 10:00:43 -0400
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 <nickolai@csail.mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Assisted-by: LLM
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
---
kernel/resource.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/kernel/resource.c~resource-report-a-devm_request_resource-conflict-under-the-lock
+++ a/kernel/resource.c
@@ -1695,10 +1695,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;
}
_
Patches currently in -mm which might be from nickolai@csail.mit.edu are
mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch
mm-truncate-fix-the-zeroing-end-of-pagecache_isize_extended.patch
resource-report-a-devm_request_resource-conflict-under-the-lock.patch
^ permalink raw reply [flat|nested] 2+ messages in thread
* + resource-report-a-devm_request_resource-conflict-under-the-lock.patch added to mm-unstable branch
@ 2026-10-17 2:19 Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2026-10-17 2:19 UTC (permalink / raw)
To: mm-commits, treding, tj, stable, ilpo.jarvinen, brads, bhelgaas,
nickolai, akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5482 bytes --]
The patch titled
Subject: resource: report a devm_request_resource() conflict under the lock
has been added to the -mm mm-unstable branch. Its filename is
resource-report-a-devm_request_resource-conflict-under-the-lock.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/resource-report-a-devm_request_resource-conflict-under-the-lock.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
Subject: resource: report a devm_request_resource() conflict under the lock
Date: Fri, 16 Oct 2026 10:00:43 -0400
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 <nickolai@csail.mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Assisted-by: LLM
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: <stable@vger.kernel.org>
---
kernel/resource.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/kernel/resource.c~resource-report-a-devm_request_resource-conflict-under-the-lock
+++ a/kernel/resource.c
@@ -1695,10 +1695,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;
}
_
Patches currently in -mm which might be from nickolai@csail.mit.edu are
mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch
mm-truncate-fix-the-zeroing-end-of-pagecache_isize_extended.patch
resource-report-a-devm_request_resource-conflict-under-the-lock.patch
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-17 2:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-17 2:18 + resource-report-a-devm_request_resource-conflict-under-the-lock.patch added to mm-unstable branch Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2026-10-17 2:19 Andrew Morton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.