linux-kernel - Re: [PATCH net-next v2 1/2] tcp: Destroy TCP-AO, TCP-MD5 keys in .sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGrbwDT7TfgQsPJh=5TE-4tuxUsn3ft52zninaRnZct+OaoAvQ@mail.gmail.com>
Date: Thu, 28 Aug 2025 21:00:40 +0100
From: Dmitry Safonov <dima@...sta.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Neal Cardwell <ncardwell@...gle.com>, Kuniyuki Iwashima <kuniyu@...gle.com>, 
	"David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Bob Gilligan <gilligan@...sta.com>, Salam Noureddine <noureddine@...sta.com>, 
	Dmitry Safonov <0x7f454c46@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/2] tcp: Destroy TCP-AO, TCP-MD5 keys in .sk_destruct()

Hi Eric,

On Thu, Aug 28, 2025 at 8:43 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Aug 28, 2025 at 1:15 AM Dmitry Safonov via B4 Relay
> <devnull+dima.arista.com@...nel.org> wrote:
...
> > +void tcp_md5_destruct_sock(struct sock *sk)
> > +{
> > +       struct tcp_sock *tp = tcp_sk(sk);
> > +
> > +       if (tp->md5sig_info) {
> > +               struct tcp_md5sig_info *md5sig;
> > +
> > +               md5sig = rcu_dereference_protected(tp->md5sig_info, 1);
> > +               tcp_clear_md5_list(sk);
> > +               call_rcu(&md5sig->rcu, tcp_md5sig_info_free_rcu);
> > +               rcu_assign_pointer(tp->md5sig_info, NULL);
>
> I would move this line before call_rcu(&md5sig->rcu, tcp_md5sig_info_free_rcu),
> otherwise the free could happen before the clear, and an UAF could occur.

Good catch! I'll reorder these in v3 just in case the next patch 2/2
would have to be reverted for any reason.

> It is not absolutely clear if this function runs under rcu_read_lock(),
> and even if it is currently safe, this could change in the future.
>
> Other than that :
>
> Reviewed-by: Eric Dumazet <edumazet@...gle.com>

Thanks,
            Dmitry