All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Eric Biggers <ebiggers@google.com>,
	Herbert Xu <herbert@gondor.apana.org.au>, <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 19:52:28 -0700	[thread overview]
Message-ID: <20220330195228.21616546@kernel.org> (raw)
In-Reply-To: <d7f55e84-ae87-ffd1-a488-a7bf6e65f3b1@huawei.com>

On Thu, 31 Mar 2022 10:35:41 +0800 Ziyang Xuan (William) wrote:
> I am thinking about is skb_copy_bits() necessary in non-TLS_1_3_VERSION
> and non-TLS_CIPHER_CHACHA20_POLY1305 scenarios?

It's not necessary there, but we should not make that change be part of
the fix, the fix should be minimal. I'll send a separate patch to move
the skb_copy_bits() call later on.

I think for the fix all you should do is replace the
	crypto_aead_ivsize(ctx->aead_recv));
line with
	prot->iv_size + prot->salt_size);

> If the inital iv+salt negotiated configuration for tx/rx offload is right
> and reliable, what is the reason why we have to extract the iv value from
> received skb instead if using the negotiated iv value? Does it can be
> modified or just follow spec that versions below TLS_1_3_VERSION?

TLS 1.3 does not send the nonce as part of the record. Instead 
the record number is always used as nonce in crypto.

      reply	other threads:[~2022-03-31  4:28 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
2022-03-30 21:44     ` Ard Biesheuvel
2022-03-31  2:35     ` Ziyang Xuan (William)
2022-03-31  2:52       ` Jakub Kicinski [this message]

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=20220330195228.21616546@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.