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

[Andy Shevchenko]

On Fri, Sep 18, 2026 at 11:27:43AM +0800, Kent Gibson wrote:
> 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:

...

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

Yes, when return value is initialised in case of error. We know that we are
going to return an error, why would we initialise? So, the answer here is
because we don't want to leak kernel memory to the user space. A short comment
makes sense to me.

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

Right, this can be done to cover all cases at once.

-- 
With Best Regards,
Andy Shevchenko