[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200818092231.GA10974@amd>
Date: Tue, 18 Aug 2020 11:22:31 +0200
From: Pavel Machek <pavel@...x.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Gilad Ben-Yossef <gilad@...yossef.com>,
Markus Elfring <Markus.Elfring@....de>,
Herbert Xu <herbert@...dor.apana.org.au>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 012/168] crypto: ccree - fix resource leak on error
path
Hi!
> Fix a small resource leak on the error path of cipher processing.
I believe this one is wrong.
> @@ -149,10 +148,19 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
> ctx_p->flow_mode = cc_alg->flow_mode;
> ctx_p->drvdata = cc_alg->drvdata;
>
> + if (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) {
> + /* Alloc hash tfm for essiv */
> + ctx_p->shash_tfm = crypto_alloc_shash("sha256-generic", 0, 0);
> + if (IS_ERR(ctx_p->shash_tfm)) {
> + dev_err(dev, "Error allocating hash tfm for ESSIV.\n");
> + return PTR_ERR(ctx_p->shash_tfm);
> + }
> + }
shash_tfm() is only allocated conditionally.
> +free_key:
> + kfree(ctx_p->user.key);
> +free_shash:
> + crypto_free_shash(ctx_p->shash_tfm);
But it is freed unconditionally, and free_shash() is not robust
against NULL pointer due to undefined behaviour in crypto_shash_tfm.
Additionally, it would be cleaner to set ctx_p->shash_tfm to NULL in
this path.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists