Re: [PATCH v2 1/2] RDMA/rxe: Fix null-ptr-deref in kernel_sock_shutdown().

Kuniyuki Iwashima
2026-04-28T05:22:42Z

On Mon, Apr 27, 2026 at 10:12 PM Zhu Yanjun <yanjun.zhu@linux.dev> wrote:
>
>
>
> 在 2026/4/27 19:15, Zhu Yanjun 写道:
> >
> > 在 2026/4/27 17:58, David Ahern 写道:
> >> On 4/27/26 6:52 PM, Kuniyuki Iwashima wrote:
> >>> To be clear, you meant implementing David' idea, right ?
> >>> I'm asking because dellink won't need locking then.
> >> dellink is not needed with my suggestion. It was added to manage
> >> basically a refcount on the socket to close on last rxe delete in the
> >
> > This is my original implementation.
> >
> > @Kuniyuki Iwashima, can you reproduce this problem in your local host or
> > other test environments?

The syzbot does not have a repro, but I think it can be
reproduced by calling newlink and dellink with multiple
threads.

newlink would trigger kmemleak splat while dellink trigger
KASAN splat.

> >
> > If yes, can you make tests after applying the commit in the link:
> > https://patchwork.kernel.org/project/linux-rdma/
> > patch/20260424043522.22901-1-yanjun.zhu@linux.dev/
> >
> > Thanks a lot.
>
> Hi, David && Kuniyuki
>
> I read the call trace again.
>
> If net namespace has already released socket in A thread, then rdma link
> del command is called in B thread to release socket.
>
> So A thread has released socket firstly, then B thread also release socket.
>
> The similar call trace would appear.
>
> The followiing is the explanation to the commit
> https://patchwork.kernel.org/project/linux-rdma/patch/20260424043522.22901-1-yanjun.zhu@linux.dev/
>
> The double-free occurs as follows:
>
> CPU 0 (Net NameSpace cleanup) CPU 1 (RDMA device removal)
> --------------------- ---------------------------
> rxe_ns_exit() rxe_link_delete() (rdma link del )

If rxe_link_delete() is in progress, it means the user thread is
alive, holding the netns refcount, and rxe_ns_exit() cannot be
called.

So, dellink() never races with rxe_ns_exit(), and it races only
with the concurrent dellink().

And when that occurs, the number of threads is not limited to
two, theoretically triple-free, quad-free, ... are possible.

> -> sk = ns_sk->rxe_sk4 -> sk = ns_sk->rxe_sk4
> -> udp_tunnel_sock_release(sk)
> [Success: First Free] -> udp_tunnel_sock_release(sk)
> [Crash: Double Free]
>
> After removing the socket release logic from rxe_ns_exit(), we ensure
> that only the device destruction path (rxe_link_delete) is responsible
> for freeing the tunnel sockets, effectively eliminating the double-free
> problem.
>
> I am not sure if this is the root cause or not.
>
> Please comment.
>
> Thanks a lot.
> Zhu Yanjun
>
> >
> > Zhu Yanjun
> >
> >> namespace.
> >
>
> --
> Best Regards,
> Yanjun.Zhu
>