lkml.org 
[lkml]   [2018]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@google.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@googlegroups.com>
> Cc: <stable@vger.kernel.org> # v4.8+
> Signed-off-by: Eric Biggers <ebiggers@google.com>

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

\
 
 \ /
  Last update: 2018-02-09 16:49    [W:0.056 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site