There are corner cases where skcipher_walk_aead_[en|de]crypt() may be
invoked with a zero sized input, which is not rejected by the walker
code, but results in the skcipher_walk structure to not be fully
initialized. This will leave stale values in its page and buffer
members, which will be subsequently passed to kfree() or free_page() by
skcipher_walk_done(), resulting in a crash if those routines fail to
identify them as in valid inputs.
Fix this by setting page and buffer to NULL even if the size of the
input is zero.
Signed-off-by: Ard Biesheuvel <[email protected]>
---
crypto/skcipher.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index a15376245416..93fdacf49697 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -511,6 +511,8 @@ static int skcipher_walk_aead_common(struct skcipher_walk *walk,
walk->nbytes = 0;
walk->iv = req->iv;
walk->oiv = req->iv;
+ walk->buffer = NULL;
+ walk->page = NULL;
if (unlikely(!walk->total))
return 0;
--
2.20.1
On Wed, May 12, 2021 at 08:44:33PM +0200, Ard Biesheuvel wrote:
> There are corner cases where skcipher_walk_aead_[en|de]crypt() may be
> invoked with a zero sized input, which is not rejected by the walker
> code, but results in the skcipher_walk structure to not be fully
> initialized. This will leave stale values in its page and buffer
> members, which will be subsequently passed to kfree() or free_page() by
> skcipher_walk_done(), resulting in a crash if those routines fail to
> identify them as in valid inputs.
>
> Fix this by setting page and buffer to NULL even if the size of the
> input is zero.
>
> Signed-off-by: Ard Biesheuvel <[email protected]>
Is this fixing an existing bug, or only a bug that got exposed by this patchset?
It would be helpful to make that clear (and if it fixes an existing bug, include
a Fixes tag).
Also, skcipher_walk_virt() doesn't set page and buffer to NULL, as it is
currently expected that skcipher_walk_done() is only called when
walk.nbytes != 0. Is something different for skcipher_walk_aead_[en|de]crypt()?
- Eric
On Wed, 12 May 2021 at 22:04, Eric Biggers <[email protected]> wrote:
>
> On Wed, May 12, 2021 at 08:44:33PM +0200, Ard Biesheuvel wrote:
> > There are corner cases where skcipher_walk_aead_[en|de]crypt() may be
> > invoked with a zero sized input, which is not rejected by the walker
> > code, but results in the skcipher_walk structure to not be fully
> > initialized. This will leave stale values in its page and buffer
> > members, which will be subsequently passed to kfree() or free_page() by
> > skcipher_walk_done(), resulting in a crash if those routines fail to
> > identify them as in valid inputs.
> >
> > Fix this by setting page and buffer to NULL even if the size of the
> > input is zero.
> >
> > Signed-off-by: Ard Biesheuvel <[email protected]>
>
> Is this fixing an existing bug, or only a bug that got exposed by this patchset?
> It would be helpful to make that clear (and if it fixes an existing bug, include
> a Fixes tag).
>
The CCM change in the last patch uncovers this issue, and I don't
think it is likely we would ever hit it anywhere else.
> Also, skcipher_walk_virt() doesn't set page and buffer to NULL, as it is
> currently expected that skcipher_walk_done() is only called when
> walk.nbytes != 0. Is something different for skcipher_walk_aead_[en|de]crypt()?
>
The difference is that zero sized inputs never make sense for
skciphers, but for AEADs, they could occur, even if they are uncommon
(the AEAD could have associated data only, and no plain/ciphertext)
But in the general case, I would assume that skcipher_walk_done() can
be called on a walk that was successfully started with
skcipher_walk_virt() without crashing, even if the scatterlist has
size zero, so perhaps we should fix that one as well.
On Wed, May 12, 2021 at 11:24:09PM +0200, Ard Biesheuvel wrote:
>
> The difference is that zero sized inputs never make sense for
> skciphers, but for AEADs, they could occur, even if they are uncommon
> (the AEAD could have associated data only, and no plain/ciphertext)
I don't see what a zero-sized input has to do with this though.
When the walk->nbytes is zero, that means that you must never
call the done function, because the walk state could be in error
in which case everything would have been freed already and calling
the done function may potentially cause a double-free.
I don't understand why in the case of AEAD you cannot structure
your code such that the done function is not called when nbytes
is zero.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, 21 May 2021 at 09:55, Herbert Xu <[email protected]> wrote:
>
> On Wed, May 12, 2021 at 11:24:09PM +0200, Ard Biesheuvel wrote:
> >
> > The difference is that zero sized inputs never make sense for
> > skciphers, but for AEADs, they could occur, even if they are uncommon
> > (the AEAD could have associated data only, and no plain/ciphertext)
>
> I don't see what a zero-sized input has to do with this though.
> When the walk->nbytes is zero, that means that you must never
> call the done function, because the walk state could be in error
> in which case everything would have been freed already and calling
> the done function may potentially cause a double-free.
>
> I don't understand why in the case of AEAD you cannot structure
> your code such that the done function is not called when nbytes
> is zero.
>
OK.