From: Jakub Kicinski <kuba@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>,
Eric Biggers <ebiggers@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ziyang Xuan <william.xuanziyang@huawei.com>, <borisp@nvidia.com>,
<john.fastabend@gmail.com>, <daniel@iogearbox.net>,
<davem@davemloft.net>, <pabeni@redhat.com>,
<netdev@vger.kernel.org>, <vakul.garg@nxp.com>,
<davejwatson@fb.com>, <linux-kernel@vger.kernel.org>,
Vadim Fedorenko <vfedorenko@novek.ru>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH net] net/tls: fix slab-out-of-bounds bug in decrypt_internal
Date: Wed, 30 Mar 2022 14:43:49 -0700 [thread overview]
Message-ID: <20220330144349.20fe978a@kernel.org> (raw)
In-Reply-To: <20220330132406.633c2da8@kernel.org>
On Wed, 30 Mar 2022 13:24:06 -0700 Jakub Kicinski wrote:
> Noob question for crypto folks, ivsize for AES CCM is reported
> as 16, but the real nonce size is 13 for TLS (q == 2, n == 13
> using NIST's variable names AFAICT). Are we required to zero out
> the rest of the buffer?
I guess we don't, set_msg_len() explicitly clears the tail of
the buffer. Hopefully KASAN won't be upset about the uninit
read in format_input(), since it memcpy()s the entire 16B of iv.
> In particular I think I've seen transient crypto failures with
> SM4 CCM in the past and zeroing the tail of the iv buffer seems
> to make the tests pass reliably.
next prev parent reply other threads:[~2022-03-30 21:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 8:50 [PATCH net] net/tls: fix slab-out-of-bounds bug in decrypt_internal Ziyang Xuan
2022-03-30 16:39 ` Jakub Kicinski
2022-03-30 20:24 ` Jakub Kicinski
2022-03-30 21:43 ` Jakub Kicinski [this message]
2022-03-30 21:44 ` Ard Biesheuvel
2022-03-31 2:35 ` Ziyang Xuan (William)
2022-03-31 2:52 ` Jakub Kicinski
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=20220330144349.20fe978a@kernel.org \
--to=kuba@kernel.org \
--cc=ardb@kernel.org \
--cc=borisp@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davejwatson@fb.com \
--cc=davem@davemloft.net \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=john.fastabend@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vakul.garg@nxp.com \
--cc=vfedorenko@novek.ru \
--cc=william.xuanziyang@huawei.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.