crypto: marvell/cesa - initialise struct mv_cesa_ahash_req
authorRussell King <rmk+kernel@arm.linux.org.uk>
Fri, 9 Oct 2015 19:43:43 +0000 (20:43 +0100)
committerHerbert Xu <herbert@gondor.apana.org.au>
Wed, 14 Oct 2015 14:23:18 +0000 (22:23 +0800)
commite72f407ee793f1455051cfa834e758afca09e4f6
tree28dd30c50cc6587bcf4475a6b2dab2536fa00678
parent9f5594c91e7cf5952ce39aff8b88c95a19a27e06
crypto: marvell/cesa - initialise struct mv_cesa_ahash_req

When a AF_ALG fd is accepted a second time (hence hash_accept() is
used), hash_accept_parent() allocates a new private context using
sock_kmalloc().  This context is uninitialised.  After use of the new
fd, we eventually end up with the kernel complaining:

marvell-cesa f1090000.crypto: dma_pool_free cesa_padding, c0627770/0 (bad dma)

where c0627770 is a random address.  Poisoning the memory allocated by
the above sock_kmalloc() produces kernel oopses within the marvell hash
code, particularly the interrupt handling.

The following simplfied call sequence occurs:

hash_accept()
  crypto_ahash_export()
    marvell hash export function
  af_alg_accept()
    hash_accept_parent() <== allocates uninitialised struct hash_ctx
  crypto_ahash_import()
    marvell hash import function

hash_ctx contains the struct mv_cesa_ahash_req in its req.__ctx member,
and, as the marvell hash import function only partially initialises
this structure, we end up with a lot of members which are left with
whatever data was in memory prior to sock_kmalloc().

Add zero-initialisation of this structure.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Boris Brezillon <boris.brezillon@free-electronc.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
drivers/crypto/marvell/hash.c