| Message ID | 20240212001340.1719944-1-vadfed@meta.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v2] net-timestamp: make sk_tskey more predictable in error path | expand |
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@amacapital.net> > Signed-off-by: Vadim Fedorenko <vadfed@meta.com> What is the difference with v1?
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@amacapital.net> >> Signed-off-by: Vadim Fedorenko <vadfed@meta.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.
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@amacapital.net> > >> Signed-off-by: Vadim Fedorenko <vadfed@meta.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 :)
On 12/02/2024 21:17, Willem de Bruijn wrote: > 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@amacapital.net> >>>> Signed-off-by: Vadim Fedorenko <vadfed@meta.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 :) omg, missing commit changes... will send V3, sorry for the noise
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 41537d18eecf..ac4995ed17c7 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -974,7 +974,7 @@ static int __ip_append_data(struct sock *sk, struct rtable *rt = (struct rtable *)cork->dst; unsigned int wmem_alloc_delta = 0; bool paged, extra_uref = false; - u32 tskey = 0; + u32 tsflags, tskey = 0; skb = skb_peek_tail(queue); @@ -982,10 +982,6 @@ static int __ip_append_data(struct sock *sk, mtu = cork->gso_size ? IP_MAX_MTU : cork->fragsize; paged = !!cork->gso_size; - if (cork->tx_flags & SKBTX_ANY_TSTAMP && - READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_OPT_ID) - tskey = atomic_inc_return(&sk->sk_tskey) - 1; - hh_len = LL_RESERVED_SPACE(rt->dst.dev); fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0); @@ -1052,6 +1048,11 @@ static int __ip_append_data(struct sock *sk, cork->length += length; + tsflags = READ_ONCE(sk->sk_tsflags); + if (cork->tx_flags & SKBTX_ANY_TSTAMP && + tsflags & SOF_TIMESTAMPING_OPT_ID) + tskey = atomic_inc_return(&sk->sk_tskey) - 1; + /* So, what's going on in the loop below? * * We use calculated fragment length to generate chained skb, @@ -1274,6 +1275,9 @@ static int __ip_append_data(struct sock *sk, cork->length -= length; IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTDISCARDS); refcount_add(wmem_alloc_delta, &sk->sk_wmem_alloc); + if (cork->tx_flags & SKBTX_ANY_TSTAMP && + tsflags & SOF_TIMESTAMPING_OPT_ID) + atomic_dec(&sk->sk_tskey); return err; } diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index a722a43dd668..42e423012c18 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1422,7 +1422,7 @@ static int __ip6_append_data(struct sock *sk, int err; int offset = 0; bool zc = false; - u32 tskey = 0; + u32 tsflags, tskey = 0; struct rt6_info *rt = (struct rt6_info *)cork->dst; struct ipv6_txoptions *opt = v6_cork->opt; int csummode = CHECKSUM_NONE; @@ -1440,10 +1440,6 @@ static int __ip6_append_data(struct sock *sk, mtu = cork->gso_size ? IP6_MAX_MTU : cork->fragsize; orig_mtu = mtu; - if (cork->tx_flags & SKBTX_ANY_TSTAMP && - READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_OPT_ID) - tskey = atomic_inc_return(&sk->sk_tskey) - 1; - hh_len = LL_RESERVED_SPACE(rt->dst.dev); fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + @@ -1538,6 +1534,11 @@ static int __ip6_append_data(struct sock *sk, flags &= ~MSG_SPLICE_PAGES; } + tsflags = READ_ONCE(sk->sk_tsflags); + if (cork->tx_flags & SKBTX_ANY_TSTAMP && + tsflags & SOF_TIMESTAMPING_OPT_ID) + tskey = atomic_inc_return(&sk->sk_tskey) - 1; + /* * Let's try using as much space as possible. * Use MTU if total length of the message fits into the MTU. @@ -1794,6 +1795,9 @@ static int __ip6_append_data(struct sock *sk, cork->length -= length; IP6_INC_STATS(sock_net(sk), rt->rt6i_idev, IPSTATS_MIB_OUTDISCARDS); refcount_add(wmem_alloc_delta, &sk->sk_wmem_alloc); + if (cork->tx_flags & SKBTX_ANY_TSTAMP && + tsflags & SOF_TIMESTAMPING_OPT_ID) + atomic_dec(&sk->sk_tskey); return err; }
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@amacapital.net> Signed-off-by: Vadim Fedorenko <vadfed@meta.com> --- net/ipv4/ip_output.c | 14 +++++++++----- net/ipv6/ip6_output.c | 14 +++++++++----- 2 files changed, 18 insertions(+), 10 deletions(-)