From: Dan Carpenter <dan.carpenter@oracle.com>
To: Guenter Roeck <groeck@google.com>
Cc: Benson Leung <bleung@chromium.org>,
Bill Richardson <wfrichar@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
Javier Martinez Canillas <javier@osg.samsung.com>,
Olof Johansson <olof@lixom.net>,
Gwendal Grignou <gwendal@chromium.org>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()
Date: Wed, 15 Dec 2021 11:19:35 +0300 [thread overview]
Message-ID: <20211215081935.GY1978@kadam> (raw)
In-Reply-To: <CABXOdTcny657JOxK-iau2Sj06a5hcDOdWFg8wKUNupgAceUU9w@mail.gmail.com>
On Tue, Dec 14, 2021 at 03:02:41PM -0800, Guenter Roeck wrote:
> On Thu, Dec 9, 2021 at 6:35 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > If bytes is larger than EC_MEMMAP_SIZE (255) then "EC_MEMMAP_SIZE -
> > bytes" is a very high unsigned value and basically offset is
> > accepted. The second problem is that it uses >= instead of > so this
> > means that we are not able to read the very last byte.
> >
> > Fixes: ec2f33ab582b ("platform/chrome: Add cros_ec_lpc driver for x86 devices")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > drivers/platform/chrome/cros_ec_lpc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c
> > index d6306d2a096f..7e1d175def9f 100644
> > --- a/drivers/platform/chrome/cros_ec_lpc.c
> > +++ b/drivers/platform/chrome/cros_ec_lpc.c
> > @@ -290,7 +290,8 @@ static int cros_ec_lpc_readmem(struct cros_ec_device *ec, unsigned int offset,
> > char *s = dest;
> > int cnt = 0;
> >
> > - if (offset >= EC_MEMMAP_SIZE - bytes)
> > + if (offset > EC_MEMMAP_SIZE ||
> > + bytes > EC_MEMMAP_SIZE - offset)
>
> I think that means we have the same problem if offset >
> EC_MEMMAP_SIZE, only now that condition isn't detected anymore because
> EC_MEMMAP_SIZE - offset is a very large number.
That's the bug which my patch addresses. (My patch is option 1).
> I think what we really want is
> if (offset + bytes > EC_MEMMAP_SIZE)
> only without the overflow. Not sure how we can get there without
> checking each part.
> if (offset > EC_MEMMAP_SIZE || bytes > EC_MEMMAP_SIZE || bytes
> + offset > EC_MEMMAP_SIZE)
That is another solution which works.
> return -EINVAL;
> Maybe that ?
> if ((u64) offset + bytes > EC_MEMMAP_SIZE)
> return -EINVAL;
A third viable solution.
I generally prefer option 2 to option 3. I generally use that in code
that I'm writing. There was one time Linus said he liked option 1
which I used here because it works regardless of the types or the valu
of EC_MEMMAP_SIZE. This code already used the bytes > size - offset
idiom so I kept it as similar as possible.
regards,
dan carpenter
next prev parent reply other threads:[~2021-12-15 8:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 14:35 [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem() Dan Carpenter
2021-12-14 23:02 ` Guenter Roeck
2021-12-15 8:19 ` Dan Carpenter [this message]
2021-12-15 15:55 ` Guenter Roeck
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=20211215081935.GY1978@kadam \
--to=dan.carpenter@oracle.com \
--cc=bleung@chromium.org \
--cc=groeck@chromium.org \
--cc=groeck@google.com \
--cc=gwendal@chromium.org \
--cc=javier@osg.samsung.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=wfrichar@chromium.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