All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Hangyu Hua <hbh25y@gmail.com>, Florian Westphal <fw@strlen.de>,
	borisp@nvidia.com, john.fastabend@gmail.com, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, davejwatson@fb.com,
	aviadye@mellanox.com, ilyal@mellanox.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf()
Date: Fri, 24 Feb 2023 14:17:40 -0800	[thread overview]
Message-ID: <20230224141740.63d5e503@kernel.org> (raw)
In-Reply-To: <Y/kwyS2n4uLn8eD0@hog>

On Fri, 24 Feb 2023 22:48:57 +0100 Sabrina Dubroca wrote:
> 2023-02-24, 13:06:25 -0800, Jakub Kicinski wrote:
> > On Fri, 24 Feb 2023 21:22:43 +0100 Sabrina Dubroca wrote:  
>  [...]  
> > > 
> > > I suggested a change of locking in do_tls_getsockopt_conf this
> > > morning [1]. The issue reported last seemed valid, but this patch is not
> > > at all what I had in mind.
> > > [1] https://lore.kernel.org/all/Y/ht6gQL+u6fj3dG@hog/  
> > 
> > Ack, I read the messages out of order, sorry.
> >   
> > > do_tls_setsockopt_conf fills crypto_info immediately from what
> > > userspace gives us (and clears it on exit in case of failure), which
> > > getsockopt could see since it's not locking the socket when it checks
> > > TLS_CRYPTO_INFO_READY. So getsockopt would progress up to the point it
> > > finally locks the socket, but if setsockopt failed, we could have
> > > cleared TLS_CRYPTO_INFO_READY and freed iv/rec_seq.  
> > 
> > Makes sense. We should just take the socket lock around all of
> > do_tls_getsockopt(), then?   
> 
> That would make things simple and consistent. My idea was just taking
> the existing lock_sock in do_tls_getsockopt_conf out of the switch and
> put it just above TLS_CRYPTO_INFO_READY.
> 
> While we're at it, should we move the
> 
>     ctx->prot_info.version != TLS_1_3_VERSION
> 
> check in do_tls_setsockopt_no_pad under lock_sock?

Yes, or READ_ONCE(), same for do_tls_getsockopt_tx_zc() and its access
on ctx->zerocopy_sendfile.

>  I don't think that
> can do anything wrong (we'd have to get past this check just before a
> failing setsockopt clears crypto_info, and even then we're just
> reading a bit from the context), it just looks a bit strange. Or just
> lock the socket around all of do_tls_setsockopt_no_pad, like the other
> options we have.

The delayed locking feels like a premature optimization, we'll keep
having such issues with new options. Hence my vote to lock all of
do_tls_getsockopt().

  reply	other threads:[~2023-02-24 22:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 10:58 [PATCH] net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf() Hangyu Hua
2023-02-24 12:06 ` Florian Westphal
2023-02-24 18:55   ` Jakub Kicinski
2023-02-24 20:22     ` Sabrina Dubroca
2023-02-24 21:06       ` Jakub Kicinski
2023-02-24 21:48         ` Sabrina Dubroca
2023-02-24 22:17           ` Jakub Kicinski [this message]
2023-02-27  3:26             ` Hangyu Hua
2023-02-27 19:07               ` Jakub Kicinski
2023-02-28  1:48                 ` Hangyu Hua

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230224141740.63d5e503@kernel.org \
    --to=kuba@kernel.org \
    --cc=aviadye@mellanox.com \
    --cc=borisp@nvidia.com \
    --cc=davejwatson@fb.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=hbh25y@gmail.com \
    --cc=ilyal@mellanox.com \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.