[PATCH] gpio: cdev: fix kernel stack leak to user-space in error path

[PATCH] gpio: cdev: fix kernel stack leak to user-space in error path

[Bartosz Golaszewski]

If we fail to acquire the GPIO chip guard in gpio_desc_to_lineinfo(), we
return immediately before zeroing the info struct we'll end up passing
to the user-space later in lineinfo_get_v1(). This may leak the kernel
stack contents. Move the memset() before trying to acquire the SRCU read
lock.

Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260912123529.7951-1-tzungbi%40kernel.org?part=3
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib-cdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index b5da6e8566dcd777ef4e7784989b722416c07fd3..ccdb3584c727613334875350cefc13a6877783f9 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -2181,11 +2181,12 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
 	unsigned long dflags;
 	const char *label;
 
+	memset(info, 0, sizeof(*info));
+
 	CLASS(gpio_chip_guard, guard)(desc);
 	if (!guard.gc)
 		return;
 
-	memset(info, 0, sizeof(*info));
 	info->offset = gpiod_hwgpio(desc);
 
 	if (desc->name)

---
base-commit: 0d9d0dbf2fddcff5859d623e90ca73c4054276e1
change-id: 20260917-gpio-cdev-stack-leak-fixes-84ad8918a6e0

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH] gpio: cdev: fix kernel stack leak to user-space in error path

[Kent Gibson]

On Thu, Sep 17, 2026 at 04:39:05PM +0200, Bartosz Golaszewski wrote:
> If we fail to acquire the GPIO chip guard in gpio_desc_to_lineinfo(), we
> return immediately before zeroing the info struct we'll end up passing
> to the user-space later in lineinfo_get_v1(). This may leak the kernel
> stack contents. Move the memset() before trying to acquire the SRCU read
> lock.
> 
> Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
> Cc: stable@vger.kernel.org
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260912123529.7951-1-tzungbi%40kernel.org?part=3
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Reviewed-by: Kent Gibson <warthog618@gmail.com>

Cheers,
Kent.

Re: [PATCH] gpio: cdev: fix kernel stack leak to user-space in error path

[Andy Shevchenko]

On Thu, Sep 17, 2026 at 04:39:05PM +0200, Bartosz Golaszewski wrote:
> If we fail to acquire the GPIO chip guard in gpio_desc_to_lineinfo(), we
> return immediately before zeroing the info struct we'll end up passing
> to the user-space later in lineinfo_get_v1(). This may leak the kernel
> stack contents. Move the memset() before trying to acquire the SRCU read
> lock.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

...

>  	unsigned long dflags;
>  	const char *label;

It might be not obvious for a reader, perhaps a short comment why it's done
here?

> +	memset(info, 0, sizeof(*info));

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpio: cdev: fix kernel stack leak to user-space in error path

[Kent Gibson]

On Thu, Sep 17, 2026 at 06:17:12PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 17, 2026 at 04:39:05PM +0200, Bartosz Golaszewski wrote:
> > If we fail to acquire the GPIO chip guard in gpio_desc_to_lineinfo(), we
> > return immediately before zeroing the info struct we'll end up passing
> > to the user-space later in lineinfo_get_v1(). This may leak the kernel
> > stack contents. Move the memset() before trying to acquire the SRCU read
> > lock.
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> ...
> 
> >  	unsigned long dflags;
> >  	const char *label;
> 
> It might be not obvious for a reader, perhaps a short comment why it's done
> here?
> 

So we should always add comments highlighting initialisation of return values?
No problem with adding one here btw, as we do it elsewhere, just
wondering if you think this should always be the case.

Hmmm, after some sleep and taking another look, what does bother me is that
when the guard was added the behaviour of gpio_desc_to_lineinfo() changed,
in that it can now fail, but its signature did not.
As a consequence, lineinfo_get() and lineinfo_get_v1() now return
empty/zeroed line info and success when the guard has failed.
Elsewhere when the guard fails the operations return -ENODEV.
So, while this patch no longer leaks stack, it would be better to propagate
the failure.  That could also make the memset ordering mute, or even a
trivial waste of CPU time, as it could prevent ANY line info being copied
to user in the failure case.

Cheers,
Kent.