From: Sabrina Dubroca <sd@queasysnail.net>
To: Hangyu Hua <hbh25y@gmail.com>
Cc: borisp@nvidia.com, john.fastabend@gmail.com, kuba@kernel.org,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: tls: fix possible info leak in tls_set_device_offload()
Date: Fri, 24 Feb 2023 08:57:30 +0100 [thread overview]
Message-ID: <Y/ht6gQL+u6fj3dG@hog> (raw)
In-Reply-To: <04c4d6ee-f893-5248-26cf-2c6d1c9b3aa5@gmail.com>
2023-02-24, 11:33:29 +0800, Hangyu Hua wrote:
> On 24/2/2023 11:07, Hangyu Hua wrote:
> > On 23/2/2023 19:15, Sabrina Dubroca wrote:
> > > 2023-02-23, 17:05:08 +0800, Hangyu Hua wrote:
> > > > After tls_set_device_offload() fails, we enter tls_set_sw_offload(). But
> > > > tls_set_sw_offload can't set cctx->iv and cctx->rec_seq to NULL
> > > > if it fails
> > > > before kmalloc cctx->iv. This may cause info leak when we call
> > > > do_tls_getsockopt_conf().
> > >
> > > Is there really an issue here?
> > >
> > > If both tls_set_device_offload and tls_set_sw_offload fail,
> > > do_tls_setsockopt_conf will clear crypto_{send,recv} from the context.
> > > Then the TLS_CRYPTO_INFO_READY in do_tls_getsockopt_conf will fail, so
> > > we won't try to access iv or rec_seq.
> > >
> >
> > My bad. I forget memzero_explicit. Then this is harmless. But I still
> > think it is better to set them to NULL like tls_set_sw_offload's error
> > path because we don't know there are another way to do this(I will
> > change the commit log). What do you think?
Yes, I guess for consistency between functions it would be ok.
> Like a rare case, there is a race condition between
> do_tls_getsockopt_conf and do_tls_setsockopt_conf while the previous
> condition is met. TLS_CRYPTO_INFO_READY(crypto_info) is not
> protected by lock_sock in do_tls_getsockopt_conf. It's just too
> difficult to satisfy both conditions at the same time.
Ugh, thanks for noticing this. We should move the lock_sock in
getsockopt before TLS_CRYPTO_INFO_READY. Do you want to write that
patch?
Thanks.
--
Sabrina
next prev parent reply other threads:[~2023-02-24 7:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 9:05 [PATCH] net: tls: fix possible info leak in tls_set_device_offload() Hangyu Hua
2023-02-23 9:25 ` Yunsheng Lin
2023-02-23 11:15 ` Sabrina Dubroca
2023-02-24 3:07 ` Hangyu Hua
2023-02-24 3:33 ` Hangyu Hua
2023-02-24 7:57 ` Sabrina Dubroca [this message]
2023-02-24 9:35 ` 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=Y/ht6gQL+u6fj3dG@hog \
--to=sd@queasysnail.net \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hbh25y@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.