linux-kernel - Re: [PATCH] crypto: sha512-mb - initialize pending lengths correctly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180209154849.GA22273@gondor.apana.org.au>
Date:   Fri, 9 Feb 2018 23:48:49 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     linux-crypto@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        Megha Dey <megha.dey@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        Eric Biggers <ebiggers@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH] crypto: sha512-mb - initialize pending lengths correctly

On Wed, Jan 24, 2018 at 12:31:27AM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> 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 <syzkaller@...glegroups.com>
> Cc: <stable@...r.kernel.org> # v4.8+
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt