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

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

在 2026/4/26 20:10, Kuniyuki Iwashima 写道:
> On Sun, Apr 26, 2026 at 7:57 PM Zhu Yanjun <yanjun.zhu@linux.dev> wrote:
>> 在 2026/4/26 9:42, David Ahern 写道:
>>> On 4/25/26 3:25 PM, Zhu Yanjun wrote:
>>>> 在 2026/4/24 23:04, Kuniyuki Iwashima 写道:
>>>>> syzbot reported null-ptr-deref in kernel_sock_shutdown(). [0]
>>>>>
>>>>> The problem is ->newlink() and ->dellink() can be called
>>>>> concurrently with no synchronisation, leading sk leak or
>>>>> double free, etc.
>>>>>
>>>>> We defer UDP tunnel allocation to the first device creation,
>>>>> but this would requrie per-netns locking.
>>>>>
>>>>> Let's allocate UDP tunnels in the __init_net hook.
>>>>>
>>>>> Now extra sock_hold() and __sock_put() are no longer needed.
>>>>>
>>>>> Note that rxe_ns_pernet_sk6() is broken and will be fixed
>>>>> in the following patch.
>>>>>
>>> ...
>>>> All the commits are functionally correct, but I noticed some regressions
>>>> when running:
>>>> make -C tools/testing/selftests/rdma/ TARGET=rdma run_tests
>>>>
>>>> After applying this commit, the UDP port 4791 starts listening in both
>>>> init_net and all other net namespaces as soon as modprobe rdma_rxe is
>>>> executed. This breaks tests that expect the port to be unoccupied until
>>>> a device is actually created.
>>> Not opening the port until an rxe device is created in that namespace
>>> needs to be kept.
>> This change alters the user-visible behavior:
>> the UDP port is now always listening per netns,
>> even without an rxe device.
>>
>> Is this intentional, or should we preserve the
>> previous lazy allocation semantics?
> I did it intentionally because before f1327abd6abe
> the port was reserved while loading the module, and
> if the tunnel creation failed, the module was unloaded.
>
> Rather I feel f1327abd6abe introduced the user-visible
> change.
>
> That said, I don't have a strong preference, so up to you
> maintainers.  Simple lockless solution vs per-newlink/dellink
> locking.
To be honest, I do not have a strong preference here, though

I lean slightly toward the per-newlink/dellink locking approach.

Both the simple lockless solution and the locking approach seem

reasonable, depending on whether we prioritize simplicity or

explicit synchronization and lifecycle clarity.

It would be helpful to get feedback from David Ahern, Leon,

and Jason to converge on a final direction.

Zhu Yanjun

>
> FWIW, there is another example that reserves a port in every
> netns while loading the module, see rds_tcp_listen_init().
>
-- 
Best Regards,
Yanjun.Zhu