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