From: Mimi Zohar <zohar@linux.ibm.com>
To: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Cc: James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Dmitry Kasatkin <dmitry.kasatkin@nokia.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>
Subject: Re: [PATCH v2] evm: Fix a small race in init_desc()
Date: Thu, 14 May 2020 18:21:50 +0000 [thread overview]
Message-ID: <1589480510.4757.5.camel@linux.ibm.com> (raw)
In-Reply-To: <19452750e36d462088f4fca3d627a090@huawei.com>
On Thu, 2020-05-14 at 07:11 +0000, Krzysztof Struczynski wrote:
> > > From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> > > This patch avoids a kernel panic due to accessing an error pointer set
> > > by crypto_alloc_shash(). It occurs especially when there are many
> > > files that require an unsupported algorithm, as it would increase the
> > > likelihood of the following race condition.
> > >
> > > Imagine we have two threads and in the first thread
> > > crypto_alloc_shash() fails and returns an error pointer.
> > >
> > > *tfm = crypto_alloc_shash(algo, 0, CRYPTO_NOLOAD);
> > > if (IS_ERR(*tfm)) {
> > > rc = PTR_ERR(*tfm); <--- FIRST THREAD HERE!
> > > pr_err("Can not allocate %s (reason: %ld)\n", algo, rc);
> > > *tfm = NULL;
> > >
> > > And the second thread is here:
> > >
> > > if (*tfm = NULL) { <--- SECOND THREAD HERE!
> > > mutex_lock(&mutex);
> > > if (*tfm)
> > > goto out;
> > >
> > > Since "*tfm" is non-NULL, we assume that it is valid and that leads to
> > > a crash when it dereferences "*tfm".
> > >
> > > desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> > > ^^^^
> > >
> > > This patch fixes the problem by introducing a temporary "tmp_tfm" and
> > > only setting "*tfm" at the very end after everything has succeeded.
> > > The other change is that I reversed the initial "if (!*tfm) {"
> > > condition and pull the code in one indent level.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> > > Reported-by: Roberto Sassu <roberto.sassu@huawei.com>
> > > Reported-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > Acked-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> Acked-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
Thanks, Roberto and Krzysztof.
This patch is now queued in the "fixes" branch.
Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Cc: James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Dmitry Kasatkin <dmitry.kasatkin@nokia.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>
Subject: Re: [PATCH v2] evm: Fix a small race in init_desc()
Date: Thu, 14 May 2020 14:21:50 -0400 [thread overview]
Message-ID: <1589480510.4757.5.camel@linux.ibm.com> (raw)
In-Reply-To: <19452750e36d462088f4fca3d627a090@huawei.com>
On Thu, 2020-05-14 at 07:11 +0000, Krzysztof Struczynski wrote:
> > > From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> > > This patch avoids a kernel panic due to accessing an error pointer set
> > > by crypto_alloc_shash(). It occurs especially when there are many
> > > files that require an unsupported algorithm, as it would increase the
> > > likelihood of the following race condition.
> > >
> > > Imagine we have two threads and in the first thread
> > > crypto_alloc_shash() fails and returns an error pointer.
> > >
> > > *tfm = crypto_alloc_shash(algo, 0, CRYPTO_NOLOAD);
> > > if (IS_ERR(*tfm)) {
> > > rc = PTR_ERR(*tfm); <--- FIRST THREAD HERE!
> > > pr_err("Can not allocate %s (reason: %ld)\n", algo, rc);
> > > *tfm = NULL;
> > >
> > > And the second thread is here:
> > >
> > > if (*tfm == NULL) { <--- SECOND THREAD HERE!
> > > mutex_lock(&mutex);
> > > if (*tfm)
> > > goto out;
> > >
> > > Since "*tfm" is non-NULL, we assume that it is valid and that leads to
> > > a crash when it dereferences "*tfm".
> > >
> > > desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> > > ^^^^
> > >
> > > This patch fixes the problem by introducing a temporary "tmp_tfm" and
> > > only setting "*tfm" at the very end after everything has succeeded.
> > > The other change is that I reversed the initial "if (!*tfm) {"
> > > condition and pull the code in one indent level.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> > > Reported-by: Roberto Sassu <roberto.sassu@huawei.com>
> > > Reported-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > Acked-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> Acked-by: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
Thanks, Roberto and Krzysztof.
This patch is now queued in the "fixes" branch.
Mimi
next prev parent reply other threads:[~2020-05-14 18:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 10:48 [bug report] evm: Check also if *tfm is an error pointer in init_desc() Dan Carpenter
2020-05-12 11:31 ` Roberto Sassu
2020-05-12 12:34 ` Dan Carpenter
2020-05-12 12:45 ` Roberto Sassu
2020-05-12 13:04 ` Dan Carpenter
2020-05-12 13:08 ` Roberto Sassu
2020-05-12 13:19 ` [PATCH] evm: Fix a small race " Dan Carpenter
2020-05-12 13:19 ` Dan Carpenter
2020-05-12 13:43 ` Roberto Sassu
2020-05-12 13:43 ` Roberto Sassu
2020-05-12 17:47 ` [PATCH v2] " Dan Carpenter
2020-05-12 17:47 ` Dan Carpenter
2020-05-14 6:47 ` Roberto Sassu
2020-05-14 6:47 ` Roberto Sassu
2020-05-14 7:11 ` Krzysztof Struczynski
2020-05-14 7:11 ` Krzysztof Struczynski
2020-05-14 18:21 ` Mimi Zohar [this message]
2020-05-14 18:21 ` Mimi Zohar
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=1589480510.4757.5.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dan.carpenter@oracle.com \
--cc=dmitry.kasatkin@nokia.com \
--cc=jmorris@namei.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=krzysztof.struczynski@huawei.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.