From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:59884 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbcBBBDR (ORCPT ); Mon, 1 Feb 2016 20:03:17 -0500 Subject: Patch "crypto: skcipher - Copy iv from desc even for 0-len walks" has been added to the 4.3-stable tree To: Jason@zx2c4.com, gregkh@linuxfoundation.org, herbert@gondor.apana.org.au Cc: , From: Date: Mon, 01 Feb 2016 17:03:16 -0800 Message-ID: <145437499692222@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled crypto: skcipher - Copy iv from desc even for 0-len walks to the 4.3-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: crypto-skcipher-copy-iv-from-desc-even-for-0-len-walks.patch and it can be found in the queue-4.3 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 70d906bc17500edfa9bdd8c8b7e59618c7911613 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" Date: Sun, 6 Dec 2015 02:51:37 +0100 Subject: crypto: skcipher - Copy iv from desc even for 0-len walks From: "Jason A. Donenfeld" 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 Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman --- crypto/ablkcipher.c | 2 +- crypto/blkcipher.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/crypto/ablkcipher.c +++ b/crypto/ablkcipher.c @@ -277,12 +277,12 @@ static int ablkcipher_walk_first(struct 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); --- a/crypto/blkcipher.c +++ b/crypto/blkcipher.c @@ -326,12 +326,12 @@ static int blkcipher_walk_first(struct b 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) Patches currently in stable-queue which might be from Jason@zx2c4.com are queue-4.3/crypto-skcipher-copy-iv-from-desc-even-for-0-len-walks.patch