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

Zhu Yanjun
2026-04-28T06:30:23Z

在 2026/4/27 22:22, Kuniyuki Iwashima 写道:
> 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.

Thread 1: rdma link del Thread 2: rdma link del
(User A calls dellink) (User B calls dellink)
| |
(1) Get Socket Pointer (2) Get Socket Pointer
sk = ns_sk->rxe_sk4 sk = ns_sk->rxe_sk4
| |
(3) Release Socket (4) Release Socket
udp_tunnel_sock_release(sk) udp_tunnel_sock_release(sk)
| |
[ FIRST FREE ] |
| [ DOUBLE FREE! ]
v v
(Memory freed) (Kernel Panic / Crash)

I think the above should explain your idea. If so, your solution makes
senses to add a per-netns mutex to synchronise.

Let us use the first solution
https://lore.kernel.org/all/20260424013759.728288-1-kuniyu@google.com/

BTW, 1) add mutex_destroy 2) take into account of rdma link add.

I am not sure if it is OK or not. @David Ahern

Thanks.

Zhu Yanjun

>
>
>> -> 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
>>