linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, krzysztof.struczynski@huawei.com,
	silviu.vlasceanu@huawei.com, stable@vger.kernel.org
Subject: Re: [PATCH 2/5] evm: Check also if *tfm is an error pointer in init_desc()
Date: Wed, 22 Apr 2020 09:45:02 -0400	[thread overview]
Message-ID: <1587563102.5738.32.camel@linux.ibm.com> (raw)
In-Reply-To: <20200325161116.7082-2-roberto.sassu@huawei.com>

Hi Roberto, Krzysztof,

On Wed, 2020-03-25 at 17:11 +0100, Roberto Sassu wrote:
> The mutex in init_desc(), introduced by commit 97426f985729 ("evm: prevent
> racing during tfm allocation") prevents two tasks to concurrently set *tfm.
> However, checking if *tfm is NULL is not enough, as crypto_alloc_shash()
> can return an error pointer. The following sequence can happen:
> 
> Task A: *tfm = crypto_alloc_shash() <= error pointer
> Task B: if (*tfm == NULL) <= *tfm is not NULL, use it
> Task B: rc = crypto_shash_init(desc) <= panic
> Task A: *tfm = NULL
> 
> This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new
> crypto context must be created.
> 
> Cc: stable@vger.kernel.org
> Fixes: 97426f985729 ("evm: prevent racing during tfm allocation")

Thank you.  True, this commit introduced the mutex, but the actual
problem is most likely the result of a crypto algorithm not being
configured.  Depending on the kernel and which crypto algorithms are
enabled, verifying an EVM signature might not be possible.  In the
embedded environment, where the entire filesystem is updated, there
shouldn't be any unknown EVM signature algorithms.

In case Greg or Sasha decide this patch should be backported,
including the context/motivation in the patch description (first
paragraph) would be helpful.

Mimi

> Co-developed-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> Signed-off-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
>  security/integrity/evm/evm_crypto.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index 35682852ddea..77ad1e5a93e4 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -91,7 +91,7 @@ static struct shash_desc *init_desc(char type, uint8_t hash_algo)
>  		algo = hash_algo_name[hash_algo];
>  	}
>  
> -	if (*tfm == NULL) {
> +	if (IS_ERR_OR_NULL(*tfm)) {
>  		mutex_lock(&mutex);
>  		if (*tfm)
>  			goto out;


  reply	other threads:[~2020-04-22 13:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 16:11 [PATCH 1/5] ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash() Roberto Sassu
2020-03-25 16:11 ` [PATCH 2/5] evm: Check also if *tfm is an error pointer in init_desc() Roberto Sassu
2020-04-22 13:45   ` Mimi Zohar [this message]
2020-04-22 15:37     ` Roberto Sassu
2020-03-25 16:11 ` [PATCH 3/5] ima: Fix ima digest hash table key calculation Roberto Sassu
2020-04-22 20:56   ` Mimi Zohar
2020-04-23 10:21     ` Roberto Sassu
2020-04-23 16:53       ` Mimi Zohar
2020-04-24 12:18         ` Roberto Sassu
2020-04-24 14:45           ` Mimi Zohar
2020-03-25 16:14 ` [PATCH 4/5] ima: Remove redundant policy rule set in add_rules() Roberto Sassu
2020-03-25 16:14   ` [PATCH 5/5] ima: Remove unused build_ima_appraise variable Roberto Sassu
2020-04-22 22:59     ` Mimi Zohar
2020-04-22 12:03 ` [PATCH 1/5] ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash() Mimi Zohar
2020-04-22 15:39   ` Roberto Sassu

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=1587563102.5738.32.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).