netdev - Re: [PATCH net v2] net-timestamp: make sk_tskey more predictable in error path

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <65cad127de7c3_1b2b61294f6@willemb.c.googlers.com.notmuch>
Date: Mon, 12 Feb 2024 21:17:11 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Vadim Fedorenko <vadfed@...a.com>, 
 Andy Lutomirski <luto@...capital.net>
Cc: Jakub Kicinski <kuba@...nel.org>, 
 "David S . Miller" <davem@...emloft.net>, 
 Willem de Bruijn <willemb@...gle.com>, 
 netdev@...r.kernel.org
Subject: Re: [PATCH net v2] net-timestamp: make sk_tskey more predictable in
 error path

Vadim Fedorenko wrote:
> On 12/02/2024 11:19, Willem de Bruijn wrote:
> > Vadim Fedorenko wrote:
> >> When SOF_TIMESTAMPING_OPT_ID is used to ambiguate timestamped datagrams,
> >> the sk_tskey can become unpredictable in case of any error happened
> >> during sendmsg(). Move increment later in the code and make decrement of
> >> sk_tskey in error path. This solution is still racy in case of multiple
> >> threads doing snedmsg() over the very same socket in parallel, but still
> >> makes error path much more predictable.
> >>
> >> Fixes: 09c2d251b707 ("net-timestamp: add key to disambiguate concurrent datagrams")
> >> Reported-by: Andy Lutomirski <luto@...capital.net>
> >> Signed-off-by: Vadim Fedorenko <vadfed@...a.com>
> > 
> > What is the difference with v1?
> 
> Ah, sorry, was in a rush.
> 
> v1 -> v2:
>   - use local boolean variable instead of checking the same conditions 
> twice.

No, I meant that the code is exactly the same :)