[3.16.y-ckt stable] Patch "crypto: skcipher - Copy iv from desc even for 0-len walks" has been added to staging queue

Luis Henriques luis.henriques at canonical.com
Fri Jan 15 18:23:28 UTC 2016


This is a note to let you know that I have just added a patch titled

    crypto: skcipher - Copy iv from desc even for 0-len walks

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

    http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt23.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

---8<------------------------------------------------------------

>From 8f142b1a80de117634cf88687ee3e9445eb80c4f Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason at zx2c4.com>
Date: Sun, 6 Dec 2015 02:51:37 +0100
Subject: crypto: skcipher - Copy iv from desc even for 0-len walks

commit 70d906bc17500edfa9bdd8c8b7e59618c7911613 upstream.

Some ciphers actually support encrypting zero length plaintexts. For
example, many AEAD modes support this. The resulting ciphertext for
those winds up being only the authentication tag, which is a result of
the key, the iv, the additional data, and the fact that the plaintext
had zero length. The blkcipher constructors won't copy the IV to the
right place, however, when using a zero length input, resulting in
some significant problems when ciphers call their initialization
routines, only to find that the ->iv parameter is uninitialized. One
such example of this would be using chacha20poly1305 with a zero length
input, which then calls chacha20, which calls the key setup routine,
which eventually OOPSes due to the uninitialized ->iv member.

Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 crypto/ablkcipher.c | 2 +-
 crypto/blkcipher.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index 520729d898fe..f02fdbefb2c6 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -276,12 +276,12 @@ static int ablkcipher_walk_first(struct ablkcipher_request *req,
 	if (WARN_ON_ONCE(in_irq()))
 		return -EDEADLK;

+	walk->iv = req->info;
 	walk->nbytes = walk->total;
 	if (unlikely(!walk->total))
 		return 0;

 	walk->iv_buffer = NULL;
-	walk->iv = req->info;
 	if (unlikely(((unsigned long)walk->iv & alignmask))) {
 		int err = ablkcipher_copy_iv(walk, tfm, alignmask);
 		if (err)
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec38564..7180cb2fe026 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -325,12 +325,12 @@ static int blkcipher_walk_first(struct blkcipher_desc *desc,
 	if (WARN_ON_ONCE(in_irq()))
 		return -EDEADLK;

+	walk->iv = desc->info;
 	walk->nbytes = walk->total;
 	if (unlikely(!walk->total))
 		return 0;

 	walk->buffer = NULL;
-	walk->iv = desc->info;
 	if (unlikely(((unsigned long)walk->iv & walk->alignmask))) {
 		int err = blkcipher_copy_iv(walk);
 		if (err)




More information about the kernel-team mailing list