Re: [libgpiod][PATCH] core: ignore positive values returned by the GPIO_V2_GET_LINE ioctl()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 24, 2024 at 11:58:16AM +0100, Bartosz Golaszewski wrote:
> On Wed, Jan 24, 2024 at 11:54 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Wed, Jan 24, 2024 at 11:39:29AM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > >
> > > If the kernel GPIO driver (erroneously) returns a positive value from one
> > > of its callbacks, it may end up being propagated to user space as
> > > a positive value returned by the call to ioctl(). Let's treat all
> > > non-zero values as errors as GPIO uAPI ioctl()s are not expected to ever
> > > return positive values. This should be addressed in the kernel but will
> > > remain a problem on older or unpatched versions so we need to sanitize it
> > > in user-space too.
> > >
> > > Reported-by: José Guilherme de Castro Rodrigues <joseguilhermebh@xxxxxxxxxxx>
> > > Fixes: b7ba732e6a93 ("treewide: libgpiod v2 implementation")
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > ---
> > >  lib/chip.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/lib/chip.c b/lib/chip.c
> > > index 7c05e53..7bf40c6 100644
> > > --- a/lib/chip.c
> > > +++ b/lib/chip.c
> > > @@ -239,7 +239,7 @@ gpiod_chip_request_lines(struct gpiod_chip *chip,
> > >               return NULL;
> > >
> > >       ret = ioctl(chip->fd, GPIO_V2_GET_LINE_IOCTL, &uapi_req);
> > > -     if (ret < 0)
> > > +     if (ret)
> > >               return NULL;
> > >
> >
> > What is errno going to be here?
> > Is errno set if the ioctl returns positive?
> >
>
> No it isn't, thanks for catching it.
>
> This patch is incomplete - we need a wrapper around ioctl() for all
> uAPI calls that will check for positive numbers and set errno to
> ERANGE (is that the right one? any other ideas?) then return -1.
>

The two things I'm looking for in an error code would be that we don't
use it already, and it isn't too confusing.

ERANGE is typically for numeric overlow, so a bit confusing.

EBADE?

Though EHWPOISON does seem fitting given the root cause ;-).

Cheers,
Kent.






[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux