public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()
@ 2021-12-09 14:35 Dan Carpenter
  2021-12-14 23:02 ` Guenter Roeck
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2021-12-09 14:35 UTC (permalink / raw)
  To: Benson Leung, Bill Richardson
  Cc: Guenter Roeck, Javier Martinez Canillas, Olof Johansson,
	Gwendal Grignou, linux-kernel, kernel-janitors

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)
 		return -EINVAL;
 
 	/* fixed length */
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Guenter Roeck @ 2021-12-14 23:02 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Benson Leung, Bill Richardson, Guenter Roeck,
	Javier Martinez Canillas, Olof Johansson, Gwendal Grignou,
	linux-kernel, kernel-janitors

 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.
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)
                return -EINVAL;
Maybe that ?
        if ((u64) offset + bytes > EC_MEMMAP_SIZE)
                return -EINVAL;

Thanks,
Guenter

>                 return -EINVAL;
>
>         /* fixed length */
> --
> 2.20.1
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()
  2021-12-14 23:02 ` Guenter Roeck
@ 2021-12-15  8:19   ` Dan Carpenter
  2021-12-15 15:55     ` Guenter Roeck
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2021-12-15  8:19 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Benson Leung, Bill Richardson, Guenter Roeck,
	Javier Martinez Canillas, Olof Johansson, Gwendal Grignou,
	linux-kernel, kernel-janitors

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] platform/chrome: cros_ec: fix read overflow in cros_ec_lpc_readmem()
  2021-12-15  8:19   ` Dan Carpenter
@ 2021-12-15 15:55     ` Guenter Roeck
  0 siblings, 0 replies; 4+ messages in thread
From: Guenter Roeck @ 2021-12-15 15:55 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Benson Leung, Bill Richardson, Guenter Roeck,
	Javier Martinez Canillas, Olof Johansson, Gwendal Grignou,
	linux-kernel, kernel-janitors

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

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@chromium.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
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-12-15 16:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2021-12-15 15:55     ` Guenter Roeck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox