All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Boris Pismenny <borisp@nvidia.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	glider@google.com, herbert@gondor.apana.org.au,
	linux-crypto@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	syzbot <syzbot+828dfc12440b4f6f305d@syzkaller.appspotmail.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Aviad Yehezkel <aviadye@nvidia.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH] net: tls: enable __GFP_ZERO upon tls_init()
Date: Fri, 30 Jun 2023 11:36:51 +0200	[thread overview]
Message-ID: <CAMj1kXFqYozjJ+qPeSApESb0Cb6CUaGXBrs5LP81ERRvb3+TAw@mail.gmail.com> (raw)
In-Reply-To: <c16e9ab9-13e0-b911-e33a-c9ae81e93a8d@I-love.SAKURA.ne.jp>

On Wed, 28 Jun 2023 at 15:49, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> syzbot is reporting uninit-value at aes_encrypt(), for block cipher assumes
> that bytes to encrypt/decrypt is multiple of block size for that cipher but
> tls_alloc_encrypted_msg() is not initializing padding bytes when
> required_size is not multiple of block cipher's block size.
>
> In order to make sure that padding bytes are automatically initialized,
> enable __GFP_ZERO flag when setsockopt(SOL_TCP, TCP_ULP, "tls") is called.
>
> Reported-by: syzbot <syzbot+828dfc12440b4f6f305d@syzkaller.appspotmail.com>
> Closes: https://syzkaller.appspot.com/bug?extid=828dfc12440b4f6f305d

Maybe I am missing something, but this syzkaller report appears to b a
huge collection of uninit-value reports, of which only one is related
to bpx_tx_verdict(), and that one has nor reproducer.

So even if this would be the right fix, I don't think closing that
issue makes sense, so? The issue refers to a couple of other
occcurences of uninit-value in aesti_encrypt, which do seem related.

> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> According to C reproducer, this problem happens when bpf_exec_tx_verdict() is
> called with lower 4 bits of required_size being 0001 and does not happen when
> being 0100. Thus, I assumed that this problem is caused by lack of initializing
> padding bytes.
> But I couldn't figure out why KMSAN reports this problem when bpf_exec_tx_verdict()
> is called with lower 4 bits of required_size being 0001 for the second time and
> does not report this problem when bpf_exec_tx_verdict() is called with lower
> 4 bits of required_size being 0001 for the first time. More deeper problem exists?
> KMSAN reporting this problem when accessing u64 relevant?
>

As Eric pointed out as well, zeroing the allocation papers over the problem.

Why are you sending this now? Do you have a reproducer for this issue?

>  net/tls/tls_main.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index f2e7302a4d96..cd5366966864 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -1025,6 +1025,7 @@ static int tls_init(struct sock *sk)
>         struct tls_context *ctx;
>         int rc = 0;
>
> +       sk->sk_allocation |= __GFP_ZERO;
>         tls_build_proto(sk);
>
>  #ifdef CONFIG_TLS_TOE
> --
> 2.34.1
>

  parent reply	other threads:[~2023-06-30  9:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 14:09 KMSAN: uninit-value in aes_encrypt (4) syzbot
2020-09-11 17:01 ` [net/tls] " Eric Biggers
2023-06-28 13:48   ` [PATCH] net: tls: enable __GFP_ZERO upon tls_init() Tetsuo Handa
2023-06-28 21:03     ` Jakub Kicinski
2023-06-28 22:15       ` Tetsuo Handa
2023-06-30  8:15         ` Eric Biggers
2023-06-30  9:36     ` Ard Biesheuvel [this message]
2023-06-30  9:52       ` Tetsuo Handa
2023-06-30 10:02         ` Ard Biesheuvel
2023-06-30 10:10           ` Alexander Potapenko
2023-06-30 10:18             ` Ard Biesheuvel
2023-06-30 11:11               ` Tetsuo Handa
2023-06-30 11:24                 ` Eric Dumazet
2023-06-30 11:32                 ` Ard Biesheuvel
2023-06-30 11:43                   ` Alexander Potapenko
2023-06-30 11:37               ` Alexander Potapenko
2023-06-30 11:49                 ` Ard Biesheuvel
2023-06-30 11:55                   ` Alexander Potapenko
2023-06-30 15:16                     ` Ard Biesheuvel
2023-06-30 15:27                       ` Jakub Kicinski
2023-06-30 15:50                         ` Ard Biesheuvel
2023-07-01  4:12                       ` Tetsuo Handa
2023-07-04 13:32                         ` Tetsuo Handa
2023-07-06 20:53                           ` Jakub Kicinski
2023-07-07  9:41                             ` Tetsuo Handa
2023-07-08 10:34                               ` Tetsuo Handa

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=CAMj1kXFqYozjJ+qPeSApESb0Cb6CUaGXBrs5LP81ERRvb3+TAw@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=aviadye@nvidia.com \
    --cc=borisp@nvidia.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=edumazet@google.com \
    --cc=glider@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=syzbot+828dfc12440b4f6f305d@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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.