linux-kernel - Re: [PATCH] crypto: ghash: Avoid null pointer dereference if no key is set.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20111014171358.GA15626@elliptictech.com>
Date:	Fri, 14 Oct 2011 13:13:58 -0400
From:	Nick Bowler <nbowler@...iptictech.com>
To:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	Herbert Xu <herbert@...dor.hengli.com.au>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] crypto: ghash: Avoid null pointer dereference if no key
 is set.

On 2011-10-14 10:37 -0400, Nick Bowler wrote:
> The ghash_update function passes a pointer to gf128mul_4k_lle which will
> be NULL if ghash_setkey is not called or if the most recent call to
> ghash_setkey failed to allocate memory.  This causes an oops.  Fix this
> up by returning an error code in the null case.
> 
> This is trivially triggered from unpriviliged userspace through the
> AF_ALG interface by simply writing to the socket without setting a key.

It looks like this can also happen in ghash_final if an evil user calls
setkey, update with a length that's not a multiple of the block size,
then setkey again (this time failing due to an allocation failure) then
final.  Thus, I suppose that final needs the same check.

v2 forthcoming...
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/