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@xxxxxxxxxxxxxxx>
> 
> ...
> 
> >  	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.