From: Mimi Zohar <zohar@linux.ibm.com>
To: Sascha Hauer <s.hauer@pengutronix.de>, linux-integrity@vger.kernel.org
Cc: kernel@pengutronix.de
Subject: Re: [PATCH] ima: fix freeing ongoing ahash_request
Date: Sun, 30 Jun 2019 19:01:44 -0400 [thread overview]
Message-ID: <1561935704.3985.55.camel@linux.ibm.com> (raw)
In-Reply-To: <20190628081449.22515-1-s.hauer@pengutronix.de>
Hi Sasha,
On Fri, 2019-06-28 at 10:14 +0200, Sascha Hauer wrote:
> integrity_kernel_read() can fail in which case we forward to call
> ahash_request_free() on a currently running request. We have to wait
> for its completion before we can free the request.
>
> This was observed by interrupting a "find / -type f -xdev -print0 | xargs -0
> cat 1>/dev/null" with ctrl-c on an IMA enabled filesystem.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> security/integrity/ima/ima_crypto.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 16a4f45863b1..6a60bdb322b1 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -271,8 +271,10 @@ static int ima_calc_file_hash_atfm(struct file *file,
> rbuf_len = min_t(loff_t, i_size - offset, rbuf_size[active]);
> rc = integrity_kernel_read(file, offset, rbuf[active],
> rbuf_len);
> - if (rc != rbuf_len)
> + if (rc != rbuf_len) {
> + ahash_wait(ahash_rc, &wait);
> goto out3;
> + }
The normal case when "rc != rbuf_len" is when the last block of the
file data is read. In that case the "ahash_wait" isn't needed. Is
there a performance penalty for adding this wait? Could you
differentiate between the last buffer and failure?
Immediately before "out3:" there's a call to ahash_wait(). There are
three "goto out3". This is the only place that skips the call to
ahash_wait(). If we do need to add it, it would be better to move the
"out3:" definition and remove the other calls to ahash_wait().
Mimi
>
> if (rbuf[1] && offset) {
> /* Using two buffers, and it is not the first
next prev parent reply other threads:[~2019-06-30 23:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 8:14 [PATCH] ima: fix freeing ongoing ahash_request Sascha Hauer
2019-06-30 23:01 ` Mimi Zohar [this message]
2019-07-01 7:27 ` Sascha Hauer
2019-07-01 11:08 ` 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=1561935704.3985.55.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=kernel@pengutronix.de \
--cc=linux-integrity@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
/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.