Linux FSCRYPT development
 help / color / mirror / Atom feed
From: Jia-Ju Bai <baijiaju1990@gmail.com>
To: tytso@mit.edu, jaegeuk@kernel.org, ebiggers@kernel.org
Cc: 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: Thu, 25 Jul 2019 11:52:07 +0800	[thread overview]
Message-ID: <33ae3693-9792-a793-5e9e-aca845c427a5@gmail.com> (raw)
In-Reply-To: <20190725033951.GA677@sol.localdomain>



On 2019/7/25 11:39, Eric Biggers wrote:
> 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.

I overlooked this if statement, thanks for the pointer.

>
>>> 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).

Okay.


Best wishes,
Jia-Ju Bai

      reply	other threads:[~2019-07-25  3:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 10:02 [PATCH] fs: crypto: keyinfo: Fix a possible null-pointer dereference in derive_key_aes() Jia-Ju Bai
2019-07-24 16:07 ` 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
2019-07-25  3:52         ` Jia-Ju Bai [this message]

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=33ae3693-9792-a793-5e9e-aca845c427a5@gmail.com \
    --to=baijiaju1990@gmail.com \
    --cc=ebiggers@kernel.org \
    --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