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

[Zhu Yanjun <yanjun.zhu@linux.dev>]

在 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?
> 
> 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 )
    -> 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