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

[Fernando Fernandez Mancera]

On 2/17/26 5:59 PM, Gerd Rausch wrote:
> 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.


AFAICS, from rds_conn_shutdown() path rds_tcp_conn_slots_available() is 
called with fan-out argument as false. Therefore, no need to get the 
peer source port.

I think that should be fine.

> 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