[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vd8Z-XmSE-JxM55rLAzMqFqm5D7B2HsQ+P_vdh==deOJQ@mail.gmail.com>
Date: Mon, 7 Mar 2022 00:23:03 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpiolib: check for overflow when reading the 'ngpios' property
On Mon, Mar 7, 2022 at 12:19 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Mon, Mar 7, 2022 at 12:11 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > The ngpio fields both in struct gpio_device as well as gpio_chip are
> > 16-bit unsigned integers. Let's not risk an overflow and check if the
> > property value represented as a 32-bit unsigned integer is not greater
> > than U16_MAX.
>
> ...
>
> > + if (ngpios > U16_MAX) {
> > + ret = EINVAL;
> > + goto err_free_descs;
> > + }
>
> I don't think it's a fatal error in this case. I would perhaps print a
> warning and simply use a masked (which is done implicitly by an
> assignment of the different type) value. Note, the above is buggy on
> the buggy DTs, where the upper part of the value is not used. After
> this patch you effectively make a regression on, yes, broken DTs.
Like
if (ngpios > U16_MAX)
chip_warn(gc, "line cnt %u is greater than supported; use
%u\n", ngpios, (u16)ngpio);
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists