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