[PATCH] RDMA/uverbs: Fix radix tree node leak in uapi_add_elm()

[PATCH] RDMA/uverbs: Fix radix tree node leak in uapi_add_elm()

[Deepanshu Kartikey]

syzbot reported a memory leak of radix_tree_node objects allocated
while registering a siw device:

  unreferenced object 0xffff88810d78f488 (size 576):
    radix_tree_node_alloc+0x81/0x1a0 lib/radix-tree.c:276
    radix_tree_insert+0x140/0x390 lib/radix-tree.c:712
    uapi_add_elm+0x61/0x140 drivers/infiniband/core/uverbs_uapi.c:41
    uverbs_alloc_api+0x85/0xc50 drivers/infiniband/core/uverbs_uapi.c:659
    ib_uverbs_add_one+0x1b1/0x350 drivers/infiniband/core/uverbs_main.c:1196
    ib_register_device+0x4fe/0x7f0 drivers/infiniband/core/device.c:1503
    siw_newlink+0x36a/0x3f0 drivers/infiniband/sw/siw/siw_main.c:433

radix_tree_insert() can fail with -ENOMEM after __radix_tree_create()
has already linked intermediate nodes into the tree, leaving them with
no entries. uapi_add_elm() frees the element on failure, but nothing
frees these empty nodes: uverbs_destroy_api() only removes populated
slots, and radix tree nodes are freed only as a side effect of
deleting an entry. The nodes are therefore leaked when the uapi is
destroyed.

On -ENOMEM, populate the same key with a dummy entry and delete it
again so that radix_tree_delete() reclaims the empty node chain.

Reported-by: syzbot+d60be66dd00b4490fa96@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d60be66dd00b4490fa96
Tested-by: syzbot+d60be66dd00b4490fa96@syzkaller.appspotmail.com
Fixes: 9ed3e5f44772 ("IB/uverbs: Build the specs into a radix tree at runtime")
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 drivers/infiniband/core/uverbs_uapi.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/infiniband/core/uverbs_uapi.c b/drivers/infiniband/core/uverbs_uapi.c
index b67db3790f03..6b2eb392b076 100644
--- a/drivers/infiniband/core/uverbs_uapi.c
+++ b/drivers/infiniband/core/uverbs_uapi.c
@@ -15,6 +15,7 @@ static int ib_uverbs_notsupp(struct uverbs_attr_bundle *attrs)
 
 static void *uapi_add_elm(struct uverbs_api *uapi, u32 key, size_t alloc_size)
 {
+	static void *dummy;
 	void *elm;
 	int rc;
 
@@ -27,6 +28,16 @@ static void *uapi_add_elm(struct uverbs_api *uapi, u32 key, size_t alloc_size)
 	rc = radix_tree_insert(&uapi->radix, key, elm);
 	if (rc) {
 		kfree(elm);
+
+		/*
+		 * A failed radix_tree_insert() can leave empty intermediate
+		 * nodes linked in the tree. They are only freed when an entry
+		 * under them is deleted, so populate and delete the slot to
+		 * reclaim them.
+		 */
+		if (rc == -ENOMEM &&
+		    !radix_tree_insert(&uapi->radix, key, &dummy))
+		    radix_tree_delete(&uapi->radix, key);
 		return ERR_PTR(rc);
 	}
 
-- 
2.43.0

Re: [PATCH] RDMA/uverbs: Fix radix tree node leak in uapi_add_elm()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] RDMA/uverbs: incomplete radix_tree_node leak fix in uapi_add_elm()
--

commit 2393d302cac044b0b4ac5a4d059afc74697b1fb2
Author: Deepanshu Kartikey <kartikey406@gmail.com>

RDMA/uverbs: Fix radix tree node leak in uapi_add_elm()

This commit attempts to fix a memory leak of intermediate radix_tree_node
objects when radix_tree_insert() fails with -ENOMEM in uapi_add_elm() by
inserting a dummy entry at the same key and immediately deleting it.

> diff --git a/drivers/infiniband/core/uverbs_uapi.c b/drivers/infiniband/core/uverbs_uapi.c
> index b67db3790f03c..91350d3479a80 100644
> --- a/drivers/infiniband/core/uverbs_uapi.c
> +++ b/drivers/infiniband/core/uverbs_uapi.c
> @@ -15,6 +15,7 @@ static int ib_uverbs_notsupp(struct uverbs_attr_bundle *attrs)
>  
>  static void *uapi_add_elm(struct uverbs_api *uapi, u32 key, size_t alloc_size)
>  {
> +	static void *dummy;
>  	void *elm;
>  	int rc;
>  
> @@ -27,6 +28,16 @@ static void *uapi_add_elm(struct uverbs_api *uapi, u32 key, size_t alloc_size)
>  	rc = radix_tree_insert(&uapi->radix, key, elm);
>  	if (rc) {
>  		kfree(elm);
> +
> +		/*
> +		 * A failed radix_tree_insert() can leave empty intermediate
> +		 * nodes linked in the tree. They are only freed when an entry
> +		 * under them is deleted, so populate and delete the slot to
> +		 * reclaim them.
> +		 */
> +		if (rc == -ENOMEM &&
> +		    !radix_tree_insert(&uapi->radix, key, &dummy))
> +		    radix_tree_delete(&uapi->radix, key);

[Severity: Medium]
Does this recovery path still leak radix_tree_node objects when the second
radix_tree_insert() in uapi_add_elm() also fails with -ENOMEM?

In lib/radix-tree.c, radix_tree_insert() -> __radix_tree_create() links
intermediate nodes at each level as it descends down to shift == 0:

lib/radix-tree.c:__radix_tree_create() {
	...
	while (shift > 0) {
		shift -= RADIX_TREE_MAP_SHIFT;
		if (child == NULL) {
			/* Have to add a child node.  */
			child = radix_tree_node_alloc(gfp, node, root, shift,
							offset, 0, 0);
			if (!child)
				return -ENOMEM;
			rcu_assign_pointer(*slot, node_to_entry(child));
			if (node)
				node->count++;
		} else if (!radix_tree_is_internal_node(child))
			break;
	...
}

When the initial radix_tree_insert(&uapi->radix, key, elm) returns -ENOMEM
after linking an upper-level node, the lower-level child node(s) down to
shift == 0 were not allocated. Freeing elm via kfree(elm) only releases a
small kmalloc object rather than a 576-byte node from
radix_tree_node_cachep.

Calling radix_tree_insert(&uapi->radix, key, &dummy) immediately afterward
must still call radix_tree_node_alloc() in __radix_tree_create() to allocate
those missing lower-level node(s) before &dummy can be inserted. Under
continued memory pressure, memcg limits, or multi-allocation fault injection,
that retry allocation can also fail with -ENOMEM (potentially after
allocating and linking another intermediate level in a 3-level tree). When
that happens, radix_tree_delete() is skipped and uverbs_destroy_api() ->
uapi_remove_range() still leaks the empty intermediate radix_tree_node
objects.

Would calling xa_destroy(&uapi->radix) in uverbs_destroy_api() after
uapi_remove_range(), or unwinding newly allocated empty nodes directly
on failure, avoid depending on a new radix_tree_node allocation to succeed
during -ENOMEM cleanup?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106013908.21789-1-kartikey406@gmail.com?part=1

Re: [PATCH] RDMA/uverbs: Fix radix tree node leak in uapi_add_elm()

[Jason Gunthorpe]

On Fri, Nov 06, 2026 at 07:09:08AM +0530, Deepanshu Kartikey wrote:
> syzbot reported a memory leak of radix_tree_node objects allocated
> while registering a siw device:
> 
>   unreferenced object 0xffff88810d78f488 (size 576):
>     radix_tree_node_alloc+0x81/0x1a0 lib/radix-tree.c:276
>     radix_tree_insert+0x140/0x390 lib/radix-tree.c:712
>     uapi_add_elm+0x61/0x140 drivers/infiniband/core/uverbs_uapi.c:41
>     uverbs_alloc_api+0x85/0xc50 drivers/infiniband/core/uverbs_uapi.c:659
>     ib_uverbs_add_one+0x1b1/0x350 drivers/infiniband/core/uverbs_main.c:1196
>     ib_register_device+0x4fe/0x7f0 drivers/infiniband/core/device.c:1503
>     siw_newlink+0x36a/0x3f0 drivers/infiniband/sw/siw/siw_main.c:433
> 
> radix_tree_insert() can fail with -ENOMEM after __radix_tree_create()
> has already linked intermediate nodes into the tree, leaving them with
> no entries. uapi_add_elm() frees the element on failure, but nothing
> frees these empty nodes: uverbs_destroy_api() only removes populated
> slots, and radix tree nodes are freed only as a side effect of
> deleting an entry. The nodes are therefore leaked when the uapi is
> destroyed.
> 
> On -ENOMEM, populate the same key with a dummy entry and delete it
> again so that radix_tree_delete() reclaims the empty node chain.

That seems like an absurd thing to do, can we fix
uverbs_destroy_api() to free the entire tree rather just populated
slots somehow?

Jason