From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Patrick Callaghan <patrickc@linux.ibm.com>,
linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Sascha Hauer <s.hauer@pengutronix.de>
Subject: Re: [PATCH] ima: avoid appraise error for hash calc interrupt
Date: Tue, 12 Nov 2019 13:12:24 -0500 [thread overview]
Message-ID: <1573582344.17949.67.camel@linux.ibm.com> (raw)
In-Reply-To: <c6a57c24-2f30-f252-0f42-8d748ede65af@linux.microsoft.com>
On Tue, 2019-11-12 at 09:33 -0800, Lakshmi Ramasubramanian wrote:
> On 11/12/2019 9:14 AM, Mimi Zohar wrote:
>
> > On Mon, 2019-11-11 at 14:29 -0800, Lakshmi Ramasubramanian wrote:
> >> On 11/11/19 11:23 AM, Patrick Callaghan wrote:
> >>
> >>> - if (rbuf_len == 0)
> >>> + if (rbuf_len == 0) { /* unexpected EOF */
> >>> + rc = -EINVAL;
> >>> break;
> >>> + }
> >>> offset += rbuf_len;
> >>
> >> Should there be an additional check to validate that (offset + rbuf_len)
> >> is less than i_size before calling cypto_shash_update (since rbuf_len is
> >> one of the parameters for this call)?
> >
> > The "while" statement enforces that.
> >
> > Mimi
>
> Yes - but that check happens after the call to crypto_shash_update().
>
> Perhaps integrity_kernel_read() will never return (rbuf_len) that will
> => violate the check in the "while" statement.
> => number of bytes read that is greater than the memory allocated for
> rbuf even in error conditions.
>
> Just making sure.
integrity_kernel_read() returns an error (< 0) or the number of bytes
read. The while statement ensures that there is more data to read, so
returning 0 is always an error.
Mimi
next prev parent reply other threads:[~2019-11-12 18:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 19:23 [PATCH] ima: avoid appraise error for hash calc interrupt Patrick Callaghan
2019-11-11 22:29 ` Lakshmi Ramasubramanian
2019-11-12 17:14 ` Mimi Zohar
2019-11-12 17:33 ` Lakshmi Ramasubramanian
2019-11-12 18:12 ` Mimi Zohar [this message]
2019-11-14 13:55 ` Patrick Callaghan
2019-11-14 18:45 ` Lakshmi Ramasubramanian
2019-11-15 15:25 ` Patrick Callaghan
2019-11-15 20:34 ` Lakshmi Ramasubramanian
2019-11-13 7:52 ` Sascha Hauer
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=1573582344.17949.67.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nramas@linux.microsoft.com \
--cc=patrickc@linux.ibm.com \
--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 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).