[PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure

[PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure

[Yuqiang Sun]

When rtrs_srv_create_path_files() fails after kobject_init_and_add() of
srv_path->kobj, its error path ends with kobject_put(&srv_path->kobj),
and the release, rtrs_srv_release(), frees srv_path.  The caller does
not expect that: process_info_req() goes on to free its tx IU through
srv_path->s.dev, and rtrs_srv_info_req_done() then closes the path,
whose close work tears down the connections, puts the session and
finally frees srv_path again in free_path().

Commit 5b7437339011 ("RDMA/rtrs: Fix use-after-free in path file
creation cleanup") reordered the cleanup inside
rtrs_srv_create_path_files() so that the helper runs before the put, but
the final put still frees srv_path under the caller.  The same pattern
exists one level down: rtrs_srv_create_stats_files() puts
srv_path->stats->kobj_stats on failure, whose release frees
srv_path->stats, which free_path() frees again.

With one allocation failure injected into kobject_init_and_add() of the
path kobject (failslab restricted to rtrs_srv_create_path_files), KASAN
reports while a client connects:

  BUG: KASAN: slab-use-after-free in rtrs_srv_info_req_done+0xe43/0x1740
  Read of size 8 by task kworker/0:1H/84
  Call Trace:
   rtrs_srv_info_req_done
   __ib_process_cq
   ib_cq_poll_work
  Freed by task 84:
   kfree
   kobject_put
   rtrs_srv_create_path_files
   rtrs_srv_info_req_done

These paths run in the server's completion worker when a client sends
its info request, and are reached when allocating or creating the sysfs
entries for the new path fails.

Keep srv_path and its stats owned by the caller on failure: the error
paths only delete what they added, and free_path(), which runs in every
case, drops the kobjects that were initialized but never made it into
sysfs, so their releases free the structures; otherwise it frees them
as before.  This keeps the kobject names from leaking, which is what the
puts in the error paths were added for.

The problem was found with kbound, a static analysis prototype that
checks whether callers rely on an object after a callee returns a value
for which the callee may have released it, on v7.2.12; it is present in
the rdma for-next branch.

Build-tested with x86_64 and arm64 allmodconfig (W=1, sparse): no new
warnings.  Run-tested under KVM (KASAN, lockdep, kmemleak), failing the
path or the stats kobject allocation with failslab during a client's
connection: before this series KASAN reports use-after-free in
rtrs_srv_info_req_done() and rtrs_srv_close_work() and a general
protection fault follows; with this series nothing is reported, also
with CONFIG_DEBUG_KOBJECT_RELEASE.  Failures of the two
sysfs_create_group() calls were not injected.  With this patch alone,
the close work still uses the session freed as described in the next
patch.  Not tested on RDMA hardware.

Fixes: 424774c9f3fa ("RDMA/rtrs: Call kobject_put in the failure path")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5 kbound
Signed-off-by: Yuqiang Sun <izaiahsun@gmail.com>
---
 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 16 +++++++---------
 drivers/infiniband/ulp/rtrs/rtrs-srv.c       | 14 +++++++++++++-
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
index 9dd9141c86a5..45ee07a98ca8 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
@@ -238,25 +238,24 @@ static int rtrs_srv_create_stats_files(struct rtrs_srv_path *srv_path)
 				   &srv_path->kobj, "stats");
 	if (err) {
 		rtrs_err(s, "kobject_init_and_add(): %pe\n", ERR_PTR(err));
-		kobject_put(&srv_path->stats->kobj_stats);
 		return err;
 	}
 	err = sysfs_create_group(&srv_path->stats->kobj_stats,
 				 &rtrs_srv_stats_attr_group);
 	if (err) {
 		rtrs_err(s, "sysfs_create_group(): %pe\n", ERR_PTR(err));
-		goto err;
+		kobject_del(&srv_path->stats->kobj_stats);
+		return err;
 	}
 
 	return 0;
-
-err:
-	kobject_del(&srv_path->stats->kobj_stats);
-	kobject_put(&srv_path->stats->kobj_stats);
-
-	return err;
 }
 
+/*
+ * On failure, the caller still owns srv_path and frees it in free_path(),
+ * which also drops the kobjects initialized here.  Do not put them here:
+ * their releases free srv_path and srv_path->stats.
+ */
 int rtrs_srv_create_path_files(struct rtrs_srv_path *srv_path)
 {
 	struct rtrs_srv_sess *srv = srv_path->srv;
@@ -296,7 +295,6 @@ int rtrs_srv_create_path_files(struct rtrs_srv_path *srv_path)
 	kobject_del(&srv_path->kobj);
 destroy_root:
 	rtrs_srv_destroy_once_sysfs_root_folders(srv_path);
-	kobject_put(&srv_path->kobj);
 
 	return err;
 }
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 5314599d29fe..641a7bf5e02c 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1584,11 +1584,23 @@ static void free_path(struct rtrs_srv_path *srv_path)
 	if (srv_path->kobj.state_in_sysfs) {
 		kobject_del(&srv_path->kobj);
 		kobject_put(&srv_path->kobj);
+		return;
+	}
+
+	/*
+	 * rtrs_srv_create_path_files() may have failed after initializing
+	 * these kobjects; then their releases free the structures.
+	 */
+	if (srv_path->stats->kobj_stats.state_initialized) {
+		kobject_put(&srv_path->stats->kobj_stats);
 	} else {
 		free_percpu(srv_path->stats->rdma_stats);
 		kfree(srv_path->stats);
-		kfree(srv_path);
 	}
+	if (srv_path->kobj.state_initialized)
+		kobject_put(&srv_path->kobj);
+	else
+		kfree(srv_path);
 }
 
 static void rtrs_srv_close_work(struct work_struct *work)

base-commit: c3e8e9451e6f1b69f685b75e0fbf14f3d0fb2539
-- 
2.53.0

Re: [PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure

[Leon Romanovsky]

On Thu, Oct 29, 2026 at 12:27:17PM +0800, Yuqiang Sun wrote:
> When rtrs_srv_create_path_files() fails after kobject_init_and_add() of
> srv_path->kobj, its error path ends with kobject_put(&srv_path->kobj),
> and the release, rtrs_srv_release(), frees srv_path.  The caller does
> not expect that: process_info_req() goes on to free its tx IU through
> srv_path->s.dev, and rtrs_srv_info_req_done() then closes the path,
> whose close work tears down the connections, puts the session and
> finally frees srv_path again in free_path().
> 
> Commit 5b7437339011 ("RDMA/rtrs: Fix use-after-free in path file
> creation cleanup") reordered the cleanup inside
> rtrs_srv_create_path_files() so that the helper runs before the put, but
> the final put still frees srv_path under the caller.  The same pattern
> exists one level down: rtrs_srv_create_stats_files() puts
> srv_path->stats->kobj_stats on failure, whose release frees
> srv_path->stats, which free_path() frees again.
> 
> With one allocation failure injected into kobject_init_and_add() of the
> path kobject (failslab restricted to rtrs_srv_create_path_files), KASAN
> reports while a client connects:
> 
>   BUG: KASAN: slab-use-after-free in rtrs_srv_info_req_done+0xe43/0x1740
>   Read of size 8 by task kworker/0:1H/84
>   Call Trace:
>    rtrs_srv_info_req_done
>    __ib_process_cq
>    ib_cq_poll_work
>   Freed by task 84:
>    kfree
>    kobject_put
>    rtrs_srv_create_path_files
>    rtrs_srv_info_req_done
> 
> These paths run in the server's completion worker when a client sends
> its info request, and are reached when allocating or creating the sysfs
> entries for the new path fails.
> 
> Keep srv_path and its stats owned by the caller on failure: the error
> paths only delete what they added, and free_path(), which runs in every
> case, drops the kobjects that were initialized but never made it into
> sysfs, so their releases free the structures; otherwise it frees them
> as before.  This keeps the kobject names from leaking, which is what the
> puts in the error paths were added for.
> 
> The problem was found with kbound, a static analysis prototype that
> checks whether callers rely on an object after a callee returns a value
> for which the callee may have released it, on v7.2.12; it is present in
> the rdma for-next branch.
> 
> Build-tested with x86_64 and arm64 allmodconfig (W=1, sparse): no new
> warnings.  Run-tested under KVM (KASAN, lockdep, kmemleak), failing the
> path or the stats kobject allocation with failslab during a client's
> connection: before this series KASAN reports use-after-free in
> rtrs_srv_info_req_done() and rtrs_srv_close_work() and a general
> protection fault follows; with this series nothing is reported, also
> with CONFIG_DEBUG_KOBJECT_RELEASE.  Failures of the two
> sysfs_create_group() calls were not injected.  With this patch alone,
> the close work still uses the session freed as described in the next
> patch.  Not tested on RDMA hardware.

Interesting claim. How did you trigger the KASAN warning in the RDMA ULP?

Thanks

> 
> Fixes: 424774c9f3fa ("RDMA/rtrs: Call kobject_put in the failure path")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5-5 kbound
> Signed-off-by: Yuqiang Sun <izaiahsun@gmail.com>
> ---
>  drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 16 +++++++---------
>  drivers/infiniband/ulp/rtrs/rtrs-srv.c       | 14 +++++++++++++-
>  2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
> index 9dd9141c86a5..45ee07a98ca8 100644
> --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
> +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
> @@ -238,25 +238,24 @@ static int rtrs_srv_create_stats_files(struct rtrs_srv_path *srv_path)
>  				   &srv_path->kobj, "stats");
>  	if (err) {
>  		rtrs_err(s, "kobject_init_and_add(): %pe\n", ERR_PTR(err));
> -		kobject_put(&srv_path->stats->kobj_stats);
>  		return err;
>  	}
>  	err = sysfs_create_group(&srv_path->stats->kobj_stats,
>  				 &rtrs_srv_stats_attr_group);
>  	if (err) {
>  		rtrs_err(s, "sysfs_create_group(): %pe\n", ERR_PTR(err));
> -		goto err;
> +		kobject_del(&srv_path->stats->kobj_stats);
> +		return err;
>  	}
>  
>  	return 0;
> -
> -err:
> -	kobject_del(&srv_path->stats->kobj_stats);
> -	kobject_put(&srv_path->stats->kobj_stats);
> -
> -	return err;
>  }
>  
> +/*
> + * On failure, the caller still owns srv_path and frees it in free_path(),
> + * which also drops the kobjects initialized here.  Do not put them here:
> + * their releases free srv_path and srv_path->stats.
> + */
>  int rtrs_srv_create_path_files(struct rtrs_srv_path *srv_path)
>  {
>  	struct rtrs_srv_sess *srv = srv_path->srv;
> @@ -296,7 +295,6 @@ int rtrs_srv_create_path_files(struct rtrs_srv_path *srv_path)
>  	kobject_del(&srv_path->kobj);
>  destroy_root:
>  	rtrs_srv_destroy_once_sysfs_root_folders(srv_path);
> -	kobject_put(&srv_path->kobj);
>  
>  	return err;
>  }
> diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> index 5314599d29fe..641a7bf5e02c 100644
> --- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> @@ -1584,11 +1584,23 @@ static void free_path(struct rtrs_srv_path *srv_path)
>  	if (srv_path->kobj.state_in_sysfs) {
>  		kobject_del(&srv_path->kobj);
>  		kobject_put(&srv_path->kobj);
> +		return;
> +	}
> +
> +	/*
> +	 * rtrs_srv_create_path_files() may have failed after initializing
> +	 * these kobjects; then their releases free the structures.
> +	 */
> +	if (srv_path->stats->kobj_stats.state_initialized) {
> +		kobject_put(&srv_path->stats->kobj_stats);
>  	} else {
>  		free_percpu(srv_path->stats->rdma_stats);
>  		kfree(srv_path->stats);
> -		kfree(srv_path);
>  	}
> +	if (srv_path->kobj.state_initialized)
> +		kobject_put(&srv_path->kobj);
> +	else
> +		kfree(srv_path);
>  }
>  
>  static void rtrs_srv_close_work(struct work_struct *work)
> 
> base-commit: c3e8e9451e6f1b69f685b75e0fbf14f3d0fb2539
> -- 
> 2.53.0
> 

Re: [PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure

[Yuqiang Sun]

On Tue, Nov 03, 2026 at 02:20:24PM +0200, Leon Romanovsky wrote:
> Interesting claim. How did you trigger the KASAN warning in the RDMA ULP?

With soft-RoCE in a KVM guest, with both ends of rtrs in the same guest,
and failslab standing in for an allocation failure:

- Kernel: rdma for-next c3e8e9451e6f, x86_64, with KASAN, RDMA_RXE,
  INFINIBAND_RTRS_CLIENT/SERVER, BLK_DEV_RNBD_CLIENT/SERVER, BLK_DEV_RAM,
  FAILSLAB and FAULT_INJECTION_STACKTRACE_FILTER, all built in.
- In the guest: "rdma link add rxe0 type rxe netdev eth0", then failslab
  is limited to call stacks through rtrs_srv_create_path_files()
  (require-start/require-end set to its range from /proc/kallsyms,
  stacktrace-depth 32, probability 100, times 1, interval N), and /dev/ram0
  is mapped through the rnbd client:
  echo "sessname=s1 path=ip:10.0.2.15 device_path=/dev/ram0" \
       > /sys/class/rnbd-client/ctl/map_device
- The server handles the client's info request in its completion worker,
  in rtrs_srv_info_req_done(). With N chosen so that the failing
  allocation is the one in kobject_init_and_add() of srv_path->kobj,
  rtrs_srv_create_path_files() fails, its kobject_put() frees srv_path
  through rtrs_srv_release(), and process_info_req() and
  rtrs_srv_info_req_done() go on using it: that is the KASAN report in
  the changelog, followed by more in rtrs_srv_close_work() and a general
  protection fault. Failing the stats kobject instead gives reports of
  the same kind.

The steps in the guest, after boot:

  ip link set eth0 up
  ip addr add 10.0.2.15/24 dev eth0
  rdma link add rxe0 type rxe netdev eth0
  f=rtrs_srv_create_path_files
  start=$(awk -v f=$f '$3 == f {print $1; exit}' /proc/kallsyms)
  end=$(sort /proc/kallsyms |
        awk -v s=$start 'found && $1 != s {print $1; exit} $1 == s {found=1}')
  F=/sys/kernel/debug/failslab
  echo 0x$start > $F/require-start
  echo 0x$end > $F/require-end
  echo 32 > $F/stacktrace-depth
  echo N > $F/task-filter
  echo N > $F/ignore-gfp-wait
  echo $N > $F/interval
  echo 1 > $F/times
  echo 2 > $F/verbose
  echo 100 > $F/probability
  echo "sessname=s1 path=ip:10.0.2.15 device_path=/dev/ram0" \
       > /sys/class/rnbd-client/ctl/map_device

With verbose=2 failslab prints the stack of the allocation it fails, so
N is found by trying N=1, 2, ... until it is the one in
kobject_init_and_add() for srv_path->kobj (21 in our build).

So it needs an allocation failure while a client connects; nothing else
is unusual. I can send the full KASAN log, the init script and the
kernel config if that helps. The client that triggers patch 2's
use-after-free from the network by sending an empty pathname (fixed by
patch 3) is not public; I can send it to you privately if you want it.

Thanks,
Yuqiang

Re: [PATCH 1/3] RDMA/rtrs-srv: Do not free the path on path file creation failure

[Leon Romanovsky]

On Tue, Nov 03, 2026 at 09:49:39PM +0800, Yuqiang Sun wrote:
> On Tue, Nov 03, 2026 at 02:20:24PM +0200, Leon Romanovsky wrote:
> > Interesting claim. How did you trigger the KASAN warning in the RDMA ULP?
> 
> With soft-RoCE in a KVM guest, with both ends of rtrs in the same guest,
> and failslab standing in for an allocation failure:
> 
> - Kernel: rdma for-next c3e8e9451e6f, x86_64, with KASAN, RDMA_RXE,
>   INFINIBAND_RTRS_CLIENT/SERVER, BLK_DEV_RNBD_CLIENT/SERVER, BLK_DEV_RAM,
>   FAILSLAB and FAULT_INJECTION_STACKTRACE_FILTER, all built in.
> - In the guest: "rdma link add rxe0 type rxe netdev eth0", then failslab
>   is limited to call stacks through rtrs_srv_create_path_files()
>   (require-start/require-end set to its range from /proc/kallsyms,
>   stacktrace-depth 32, probability 100, times 1, interval N), and /dev/ram0
>   is mapped through the rnbd client:
>   echo "sessname=s1 path=ip:10.0.2.15 device_path=/dev/ram0" \
>        > /sys/class/rnbd-client/ctl/map_device
> - The server handles the client's info request in its completion worker,
>   in rtrs_srv_info_req_done(). With N chosen so that the failing
>   allocation is the one in kobject_init_and_add() of srv_path->kobj,
>   rtrs_srv_create_path_files() fails, its kobject_put() frees srv_path
>   through rtrs_srv_release(), and process_info_req() and
>   rtrs_srv_info_req_done() go on using it: that is the KASAN report in
>   the changelog, followed by more in rtrs_srv_close_work() and a general
>   protection fault. Failing the stats kobject instead gives reports of
>   the same kind.
> 
> The steps in the guest, after boot:
> 
>   ip link set eth0 up
>   ip addr add 10.0.2.15/24 dev eth0
>   rdma link add rxe0 type rxe netdev eth0
>   f=rtrs_srv_create_path_files
>   start=$(awk -v f=$f '$3 == f {print $1; exit}' /proc/kallsyms)
>   end=$(sort /proc/kallsyms |
>         awk -v s=$start 'found && $1 != s {print $1; exit} $1 == s {found=1}')
>   F=/sys/kernel/debug/failslab
>   echo 0x$start > $F/require-start
>   echo 0x$end > $F/require-end
>   echo 32 > $F/stacktrace-depth
>   echo N > $F/task-filter
>   echo N > $F/ignore-gfp-wait
>   echo $N > $F/interval
>   echo 1 > $F/times
>   echo 2 > $F/verbose
>   echo 100 > $F/probability
>   echo "sessname=s1 path=ip:10.0.2.15 device_path=/dev/ram0" \
>        > /sys/class/rnbd-client/ctl/map_device
> 
> With verbose=2 failslab prints the stack of the allocation it fails, so
> N is found by trying N=1, 2, ... until it is the one in
> kobject_init_and_add() for srv_path->kobj (21 in our build).
> 
> So it needs an allocation failure while a client connects; nothing else
> is unusual. I can send the full KASAN log, the init script and the
> kernel config if that helps. The client that triggers patch 2's
> use-after-free from the network by sending an empty pathname (fixed by
> patch 3) is not public; I can send it to you privately if you want it.

No, I don't need it. I was just curious what “no RDMA hardware” means.

Thanks

> 
> Thanks,
> Yuqiang

[PATCH 2/3] RDMA/rtrs-srv: Balance the session device reference in sysfs setup

[Yuqiang Sun]

The session device is initialized in get_or_create_srv(), and the
reference that device_initialize() takes is meant to be dropped last, by
free_srv().  Each path takes one more reference, which
rtrs_srv_destroy_once_sysfs_root_folders() drops when the path goes
away.  On the failure paths of the path sysfs setup this does not add
up:

- rtrs_srv_create_once_sysfs_root_folders() calls put_device() when
  device_add() or the creation of the "paths" kobject fails, then
  unlocks srv->paths_mutex;
- rtrs_srv_create_path_files() calls
  rtrs_srv_destroy_once_sysfs_root_folders() when a later step fails,
  but the per-path reference is only taken by process_info_req() after
  rtrs_srv_create_path_files() succeeds.

Both drop the base reference, so rtrs_srv_dev_release() frees the
session while it is still locked, on ctx->srv_list and used by its
paths: the mutex_unlock() writes to freed memory, and the path's close
work later uses and puts the freed session again.  In addition,
srv->dev_ref stays incremented when the first helper fails, so the next
path of the session skips the setup although the device and the "paths"
kobject do not exist.

With one allocation failure injected into device_add() (failslab
restricted to rtrs_srv_create_path_files, into which the helper is
inlined), KASAN reports while a client connects:

  BUG: KASAN: slab-use-after-free in __mutex_unlock_slowpath
  Call Trace:
   mutex_unlock
   rtrs_srv_create_path_files
   rtrs_srv_info_req_done
   __ib_process_cq
  Freed by task 25:
   kfree
   device_release
   kobject_put
   rtrs_srv_create_path_files
   rtrs_srv_info_req_done

and with the failure injected into kobject_init_and_add() of the path
kobject instead, once the previous patch keeps srv_path alive:

  BUG: KASAN: slab-use-after-free in rtrs_srv_close_work
  Freed by task 88:
   kfree
   device_release
   kobject_put
   rtrs_srv_create_path_files
   rtrs_srv_info_req_done

This runs in the server's completion worker when a path sends its info
request.  Besides allocation failures in the sysfs setup, device_add()
also fails when the client sends an empty pathname, which the next
patch rejects.

Take the per-path reference in rtrs_srv_create_once_sysfs_root_folders()
on success, instead of in process_info_req(), so that the put in
rtrs_srv_destroy_once_sysfs_root_folders() is balanced on every path,
and do not put the device when the helper itself fails.  Undo the
dev_ref increment on every failure, including dev_set_name().  The
device is still released, together with its name, by the put_device()
in free_srv().

The problem was found while checking at runtime, with the fault
injection described above, a report of the kbound static analysis
prototype for the same function, on v7.2.12; it is present in the rdma
for-next branch.

Build-tested with x86_64 and arm64 allmodconfig (W=1, sparse): no new
warnings.  Run-tested under KVM (KASAN, lockdep, kmemleak) by failing,
with failslab, each allocation of dev_set_name(), device_add() and the
"paths" kobject, and the path kobject, during a client's connection:
before this series KASAN reports the use-after-free above, with this
series nothing is reported, also with CONFIG_DEBUG_KOBJECT_RELEASE.
Mapping, I/O and unmapping without fault injection still work.  Not
tested on RDMA hardware.

Fixes: baa5b28b7a47 ("RDMA/rtrs-srv: Replace device_register with device_initialize and device_add")
Fixes: e2853c49477d ("RDMA/rtrs-srv-sysfs: fix missing put_device")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5 kbound
Signed-off-by: Yuqiang Sun <izaiahsun@gmail.com>
---
 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 21 +++++++++++++-------
 drivers/infiniband/ulp/rtrs/rtrs-srv.c       |  1 -
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
index 45ee07a98ca8..8de3963ca791 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c
@@ -162,12 +162,12 @@ static int rtrs_srv_create_once_sysfs_root_folders(struct rtrs_srv_path *srv_pat
 		/*
 		 * Device needs to be registered only on the first session
 		 */
-		goto unlock;
+		goto get;
 	}
 	srv->dev.class = &rtrs_dev_class;
 	err = dev_set_name(&srv->dev, "%s", srv_path->s.sessname);
 	if (err)
-		goto unlock;
+		goto dec_ref;
 
 	/*
 	 * Suppress user space notification until
@@ -177,20 +177,27 @@ static int rtrs_srv_create_once_sysfs_root_folders(struct rtrs_srv_path *srv_pat
 	err = device_add(&srv->dev);
 	if (err) {
 		pr_err("device_add(): %pe\n", ERR_PTR(err));
-		put_device(&srv->dev);
-		goto unlock;
+		goto dec_ref;
 	}
 	srv->kobj_paths = kobject_create_and_add("paths", &srv->dev.kobj);
 	if (!srv->kobj_paths) {
 		err = -ENOMEM;
 		pr_err("kobject_create_and_add(): %pe\n", ERR_PTR(err));
 		device_del(&srv->dev);
-		put_device(&srv->dev);
-		goto unlock;
+		goto dec_ref;
 	}
 	dev_set_uevent_suppress(&srv->dev, false);
 	kobject_uevent(&srv->dev.kobj, KOBJ_ADD);
-unlock:
+get:
+	/* Dropped in rtrs_srv_destroy_once_sysfs_root_folders() */
+	get_device(&srv->dev);
+	mutex_unlock(&srv->paths_mutex);
+
+	return 0;
+
+dec_ref:
+	/* The reference from device_initialize() is dropped by free_srv() */
+	srv->dev_ref--;
 	mutex_unlock(&srv->paths_mutex);
 
 	return err;
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 641a7bf5e02c..56f0ab5a7619 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -879,7 +879,6 @@ static int process_info_req(struct rtrs_srv_con *con,
 	if (err)
 		goto iu_free;
 	kobject_get(&srv_path->kobj);
-	get_device(&srv_path->srv->dev);
 	err = rtrs_srv_change_state(srv_path, RTRS_SRV_CONNECTED);
 	if (!err) {
 		rtrs_err(s, "rtrs_srv_change_state() failed\n");
-- 
2.53.0

[PATCH 3/3] RDMA/rtrs-srv: Reject an empty pathname

[Yuqiang Sun]

process_info_req() uses the pathname sent by the client as the name of
the session device and rejects names containing '/' or '.', but it
accepts an empty one.  dev_set_name() succeeds for it, and device_add()
then fails in kobject_add_internal(), which warns about the empty name.

Reject an empty pathname together with the other invalid ones.

Build-tested with x86_64 and arm64 allmodconfig (W=1, sparse): no new
warnings.  Run-tested under KVM with KASAN, lockdep and kmemleak, using
a small user-space rtrs client that sends an empty pathname: the server
now rejects it at the check above, nothing is reported, and an ordinary
rnbd map, I/O and unmap afterwards still work.  Not tested on RDMA
hardware.

Fixes: dea7bb3ad3e0 ("RDMA/rtrs: Do not allow sessname to contain special symbols / and .")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5 kbound
Signed-off-by: Yuqiang Sun <izaiahsun@gmail.com>
---
 drivers/infiniband/ulp/rtrs/rtrs-srv.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 56f0ab5a7619..d34a177f7ba2 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -823,6 +823,10 @@ static int process_info_req(struct rtrs_srv_con *con,
 		return err;
 	}
 
+	if (!msg->pathname[0]) {
+		rtrs_err(s, "pathname cannot be empty\n");
+		return -EINVAL;
+	}
 	if (strchr(msg->pathname, '/') || strchr(msg->pathname, '.')) {
 		rtrs_err(s, "pathname cannot contain / and .\n");
 		return -EINVAL;
-- 
2.53.0