From: Jakub Kicinski <kuba@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
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: Wed, 28 Jun 2023 14:03:17 -0700 [thread overview]
Message-ID: <20230628140317.756e61d3@kernel.org> (raw)
In-Reply-To: <c16e9ab9-13e0-b911-e33a-c9ae81e93a8d@I-love.SAKURA.ne.jp>
On Wed, 28 Jun 2023 22:48:01 +0900 Tetsuo Handa 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.
Sounds odd, so crypto layer reads beyond what we submitted as
the buffer? I don't think the buffer needs to be aligned, so
the missing bits may well fall into a different (unmapped?) page.
This needs more careful investigation. Always zeroing the input
is just covering up the real issue.
next prev parent reply other threads:[~2023-06-28 21:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0000000000008a7ae505aef61db1@google.com>
2020-09-11 17:01 ` [net/tls] Re: KMSAN: uninit-value in aes_encrypt (4) Eric Biggers
[not found] ` <c16e9ab9-13e0-b911-e33a-c9ae81e93a8d@I-love.SAKURA.ne.jp>
2023-06-28 21:03 ` Jakub Kicinski [this message]
2023-06-28 22:15 ` [PATCH] net: tls: enable __GFP_ZERO upon tls_init() Tetsuo Handa
2023-06-30 8:15 ` Eric Biggers
2023-06-30 9:36 ` Ard Biesheuvel
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=20230628140317.756e61d3@kernel.org \
--to=kuba@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).