linux-kernel - Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CABXOdTceL3RBfzWTZ1SadGLvnRq7P7VdC_jTM5eVRqn3y3vWnQ@mail.gmail.com>
Date:   Wed, 15 Dec 2021 07:55:23 -0800
From:   Guenter Roeck <groeck@...gle.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Benson Leung <bleung@...omium.org>,
        Bill Richardson <wfrichar@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Olof Johansson <olof@...om.net>,
        Gwendal Grignou <gwendal@...omium.org>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()

On Wed, Dec 15, 2021 at 12:20 AM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> 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@...cle.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@...cle.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).
>

Ah yes, for some reason I overlooked the "offset > EC_MEMMAP_SIZE"
part in your patch. Sorry, I must have been blind.

Reviewed-by: Guenter Roeck <groeck@...omium.org>

Guenter

> > 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
>