core: ignore positive values returned by the GPIO_V2_GET_LINE ioctl()
Subsystems (2)
PATCH 1/1 core: ignore positive values returned by the GPIO_V2_GET_LINE ioctl()
From: Bartosz Golaszewski <[email protected]>
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.
--- lib/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/chip.c +1 -1
@@ -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 ; request =gpiod_line_request_from_uapi (&uapi_req, info.name);
Signature · 1 line
2.40.1
Quoted 22 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.Fixes b7ba732e6a93 ("treewide: libgpiod v2 implementation")Signed-off-by Bartosz Golaszewski <[email protected]>--- lib/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)lib/chip.c +0
-0
lib/chip.c gpiod_chip_request_lines(struct gpiod_chip *chip, · line 244
Quoted 7 lines
lib/chip.c +1
-1@@ -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?
Cheers,
Kent.
Quoted 26 lines · Kent Gibson
Quoted 24 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.Fixes b7ba732e6a93 ("treewide: libgpiod v2 implementation")Signed-off-by Bartosz Golaszewski <[email protected]>--- lib/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)lib/chip.c +0
-0@@ -239,7 +239,7 @@ gpiod_chip_request_lines(struct gpiod_chip *chip,return NULL ;
Quoted 9 lines
lib/chip.c gpiod_chip_request_lines(struct gpiod_chip *chip, · line 244
Quoted 5 lines
lib/chip.c +1
-1ret =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
Quoted 37 lines · Bartosz Golaszewski
Quoted 26 lines · Kent Gibson
Quoted 24 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.Fixes b7ba732e6a93 ("treewide: libgpiod v2 implementation")Signed-off-by Bartosz Golaszewski <[email protected]>--- lib/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)lib/chip.c +0
-0@@ -239,7 +239,7 @@ gpiod_chip_request_lines(struct gpiod_chip *chip,return NULL ;Quoted 9 lines
lib/chip.c gpiod_chip_request_lines(struct gpiod_chip *chip, · line 244
Quoted 5 lines
lib/chip.c +1
-1ret =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?
Quoted 6 lines
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.
Quoted 46 lines · Kent Gibson
Quoted 37 lines · Bartosz Golaszewski
Quoted 26 lines · Kent Gibson
Quoted 24 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.Fixes b7ba732e6a93 ("treewide: libgpiod v2 implementation")Signed-off-by Bartosz Golaszewski <[email protected]>--- lib/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)lib/chip.c +0
-0@@ -239,7 +239,7 @@ gpiod_chip_request_lines(struct gpiod_chip *chip,return NULL ;Quoted 9 lines
lib/chip.c gpiod_chip_request_lines(struct gpiod_chip *chip, · line 244
Quoted 5 lines
lib/chip.c +1
-1ret =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?Quoted 6 lines
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.
Quoted 6 lines
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?
Yeah, I think this one will do. I was thinking about EREMOTEIO but "Invalid exchange" sounds the most fitting.
Bart
Quoted 7 lines
Though EHWPOISON does seem fitting given the root cause ;-).
Cheers,
Kent.