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

[Leon Romanovsky <leon@kernel.org>]

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