From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:38598 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755034AbeBOIe7 (ORCPT ); Thu, 15 Feb 2018 03:34:59 -0500 Subject: Patch "crypto: sha512-mb - initialize pending lengths correctly" has been added to the 4.15-stable tree To: ebiggers@google.com, gregkh@linuxfoundation.org, herbert@gondor.apana.org.au, syzkaller@googlegroups.com Cc: , From: Date: Thu, 15 Feb 2018 09:33:58 +0100 Message-ID: <151868363896203@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: sha512-mb - initialize pending lengths correctly to the 4.15-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-sha512-mb-initialize-pending-lengths-correctly.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From eff84b379089cd8b4e83599639c1f5f6e34ef7bf Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Wed, 24 Jan 2018 00:31:27 -0800 Subject: crypto: sha512-mb - initialize pending lengths correctly From: Eric Biggers commit eff84b379089cd8b4e83599639c1f5f6e34ef7bf upstream. The SHA-512 multibuffer code keeps track of the number of blocks pending in each lane. The minimum of these values is used to identify the next lane that will be completed. Unused lanes are set to a large number (0xFFFFFFFF) so that they don't affect this calculation. However, it was forgotten to set the lengths to this value in the initial state, where all lanes are unused. As a result it was possible for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing a NULL pointer dereference. Specifically this could happen in the case where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data, so it then called sha_complete_job() without having actually submitted any blocks to the multi-buffer code. This hit a NULL pointer dereference if another task happened to have submitted blocks concurrently to the same CPU and the flush timer had not yet expired. Fix this by initializing sha512_mb_mgr->lens correctly. As usual, this bug was found by syzkaller. Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2") Reported-by: syzbot Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman --- arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c +++ b/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c @@ -57,10 +57,12 @@ void sha512_mb_mgr_init_avx2(struct sha5 { unsigned int j; - state->lens[0] = 0; - state->lens[1] = 1; - state->lens[2] = 2; - state->lens[3] = 3; + /* initially all lanes are unused */ + state->lens[0] = 0xFFFFFFFF00000000; + state->lens[1] = 0xFFFFFFFF00000001; + state->lens[2] = 0xFFFFFFFF00000002; + state->lens[3] = 0xFFFFFFFF00000003; + state->unused_lanes = 0xFF03020100; for (j = 0; j < 4; j++) state->ldata[j].job_in_lane = NULL; Patches currently in stable-queue which might be from ebiggers@google.com are queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch queue-4.15/ubifs-free-the-encrypted-symlink-target.patch queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch queue-4.15/crypto-poly1305-remove-setkey-method.patch queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch