From: Eric Biggers <ebiggers@kernel.org>
To: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: tytso@mit.edu, jaegeuk@kernel.org, linux-fscrypt@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH] fs: crypto: keyinfo: Fix a possible null-pointer dereference in derive_key_aes()
Date: Wed, 24 Jul 2019 20:39:51 -0700 [thread overview]
Message-ID: <20190725033951.GA677@sol.localdomain> (raw)
In-Reply-To: <9740973d-6e59-e4df-7097-4e5d0da89235@gmail.com>
On Thu, Jul 25, 2019 at 11:33:53AM +0800, Jia-Ju Bai wrote:
> Sorry, I forgot to send to Eric, so send it again.
>
> On 2019/7/25 11:30, Jia-Ju Bai wrote:
> >
> >
> > On 2019/7/25 0:07, Eric Biggers wrote:
> > > [+Cc linux-crypto]
> > >
> > > On Wed, Jul 24, 2019 at 06:02:04PM +0800, Jia-Ju Bai wrote:
> > > > In derive_key_aes(), tfm is assigned to NULL on line 46, and then
> > > > crypto_free_skcipher(tfm) is executed.
> > > >
> > > > crypto_free_skcipher(tfm)
> > > > crypto_skcipher_tfm(tfm)
> > > > return &tfm->base;
> > > >
> > > > Thus, a possible null-pointer dereference may occur.
> > > This analysis is incorrect because only the address &tfm->base is taken.
> > > There's no pointer dereference.
> > >
> > > In fact all the crypto_free_*() functions are no-ops on NULL
> > > pointers, and many
> > > other callers rely on it. So there's no bug here.
> >
> > Thanks for the reply :)
> > I admit that "&tfm->base" is not a null-pointer dereference when tfm is
> > NULL.
> > But I still think crypto_free_skcipher(tfm) can cause security problems
> > when tfm is NULL.
> >
> > Looking at the code:
> >
> > static inline void crypto_free_skcipher(struct crypto_skcipher *tfm)
> > {
> > crypto_destroy_tfm(tfm, crypto_skcipher_tfm(tfm));
> > }
> >
> > static inline struct crypto_tfm *crypto_skcipher_tfm(
> > struct crypto_skcipher *tfm)
> > {
> > return &tfm->base;
> > }
> >
> > void crypto_destroy_tfm(void *mem, struct crypto_tfm *tfm)
> > {
> > struct crypto_alg *alg;
> >
> > if (unlikely(!mem))
> > return;
When the original pointer is NULL, mem == NULL here so crypto_destroy_tfm() is a
no-op.
> > Besides, I also find that some kernel modules check tfm before calling
> > crypto_free_*(), such as:
> >
> > drivers/crypto/vmx/aes_xts.c:
> > if (ctx->fallback) {
> > crypto_free_skcipher(ctx->fallback);
> > ctx->fallback = NULL;
> > }
> >
> > net/rxrpc/rxkad.c:
> > if (conn->cipher)
> > crypto_free_skcipher(conn->cipher);
> >
> > drivers/crypto/chelsio/chcr_algo.c:
> > if (ablkctx->aes_generic)
> > crypto_free_cipher(ablkctx->aes_generic);
> >
> > net/mac80211/wep.c:
> > if (!IS_ERR(local->wep_tx_tfm))
> > crypto_free_cipher(local->wep_tx_tfm);
> >
Well, people sometimes do that for kfree() too. But that doesn't mean it's
needed, or that it's the preferred style (it's not).
- Eric
next prev parent reply other threads:[~2019-07-25 3:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190724100204.2009-1-baijiaju1990@gmail.com>
2019-07-24 16:07 ` [PATCH] fs: crypto: keyinfo: Fix a possible null-pointer dereference in derive_key_aes() Eric Biggers
2019-07-25 3:30 ` Jia-Ju Bai
2019-07-25 3:33 ` Jia-Ju Bai
2019-07-25 3:39 ` Eric Biggers [this message]
2019-07-25 3:52 ` Jia-Ju Bai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190725033951.GA677@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=baijiaju1990@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox