Re: [syzbot] [net?] possible deadlock in inet6_getname

[Gerd Rausch <gerd.rausch@oracle.com>]

Hi,

On 2026-02-14 10:25, Fernando Fernandez Mancera wrote:
> --- a/net/rds/tcp_listen.c
> +++ b/net/rds/tcp_listen.c
> @@ -59,30 +59,12 @@ void rds_tcp_keepalive(struct socket *sock)
>   static int
>   rds_tcp_get_peer_sport(struct socket *sock)
>   {
> -    union {
[...]
> -    } else {
> -        sport = -1;
> -    }
> +    struct sock *sk = sock->sk;
> +
> +    if (!sk)
> +        return -1;
> 
> -    return sport;
> +    return ntohs(inet_sk(sk)->inet_dport);
>   }
> 
> It would be safe from rds_tcp_accept_one() path as the new_sock has a reference count of 1 and no other component should be to release it.
> 
> In rds_tcp_conn_slots_available() path, fan-out can be only performed from receive path, AFAIU if data is being processed from the socket we should always be holding a lock.
> 
> If these premises are not correct, we can always make this conditional. But getting rid of the kernel_getpeername() call is performance-wise too.
> 

rds_tcp_conn_slots_available() can also be called from rds_conn_shutdown(),
where no "rds_tcp.ko" backend specific lock is held.

This is very solvable though.

Worst case, we can distinguish between the paths where a lock_sock()
is already held from those that don't.

> I am testing this against the syzbot report/reproducer.
> 

Thanks,

   Gerd