Re: [PATCH net-next v2 5/9] net/rds: unlink transport nodes before a possibly deferred connection free

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] rds_ib_destroy_nodev_conns() uses list_splice() without reinitializing the source list, causing a use-after-free write on subsequent resweep invocations.
--

commit cee612cc1485655f9584ac5a60a9a25e2010e66b
Author: Allison Henderson <achender@kernel.org>

net/rds: unlink transport nodes before a possibly deferred connection free

This patch updates RDS transport teardown helpers to unlink nodes from their
stack-based temporary lists before destroying the connection. This prevents
a memory corruption where a deferred connection free attempts to unlink a
node from a stack frame that has already disappeared.

> diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
> index db7e92e7bd29f..b30f2a3715878 100644
> --- a/net/rds/ib_rdma.c
> +++ b/net/rds/ib_rdma.c
> @@ -168,8 +168,18 @@ void rds_ib_destroy_nodev_conns(void)
>  	list_splice(&ib_nodev_conns, &tmp_list);

[Severity: High]
This isn't a bug introduced by this patch, but it existed before and is not
addressed in this series. Does this list_splice() leave the original list head
dangling?

If rds_ib_destroy_nodev_conns() is called multiple times, such as when used
as a resweep callback from rds_conn_wait_conns_freed() during module unload,
subsequent invocations might see a non-empty ib_nodev_conns list because
list_splice() does not re-initialize the source list.

Could splicing this list again result in a use-after-free write to the prev
and next pointers of nodes that were already moved to a temporary stack list
and potentially freed? I notice rds_loop_exit() explicitly calls
INIT_LIST_HEAD() after splicing. Would using list_splice_init() be safer here?

>  	spin_unlock_irq(&ib_nodev_conns_lock);
>  
> -	list_for_each_entry_safe(ic, _ic, &tmp_list, ib_node)
> +	/* rds_conn_destroy() can return before the connection is freed,
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912035027.27447-1-achender@kernel.org?part=5