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

[PATCH v2] 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. Make gpio_desc_to_lineinfo() return int so that the
-ENODEV returned on failure to acquire the guard can be propagated to
the callers.

While not strictly necessary: move the memset() before trying to acquire
the SRCU read lock too for good measure.

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>
---
Changes in v2:
- Make gpio_desc_to_lineinfo() return an integer return value so that
  the error code returned in case of a failure to acquire the guard can
  be propagated down the stack
- Link to v1: https://patch.msgid.link/20260917-gpio-cdev-stack-leak-fixes-v1-1-2bb52879e49c@oss.qualcomm.com
---
 drivers/gpio/gpiolib-cdev.c | 33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index b5da6e8566dcd777ef4e7784989b722416c07fd3..f8ef7367b8c856986237dcc3a425a7152fc2db20 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -2174,18 +2174,19 @@ static void gpio_v2_line_info_changed_to_v1(
 
 #endif /* CONFIG_GPIO_CDEV_V1 */
 
-static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
-				  struct gpio_v2_line_info *info, bool atomic)
+static int gpio_desc_to_lineinfo(struct gpio_desc *desc,
+				 struct gpio_v2_line_info *info, bool atomic)
 {
 	u32 debounce_period_us;
 	unsigned long dflags;
 	const char *label;
 
+	memset(info, 0, sizeof(*info));
+
 	CLASS(gpio_chip_guard, guard)(desc);
 	if (!guard.gc)
-		return;
+		return -ENODEV;
 
-	memset(info, 0, sizeof(*info));
 	info->offset = gpiod_hwgpio(desc);
 
 	if (desc->name)
@@ -2260,6 +2261,8 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
 							debounce_period_us;
 		info->num_attrs++;
 	}
+
+	return 0;
 }
 
 struct gpio_chardev_data {
@@ -2311,6 +2314,7 @@ static int lineinfo_get_v1(struct gpio_chardev_data *cdev, void __user *ip,
 	struct gpio_desc *desc;
 	struct gpioline_info lineinfo;
 	struct gpio_v2_line_info lineinfo_v2;
+	int ret;
 
 	if (copy_from_user(&lineinfo, ip, sizeof(lineinfo)))
 		return -EFAULT;
@@ -2328,7 +2332,10 @@ static int lineinfo_get_v1(struct gpio_chardev_data *cdev, void __user *ip,
 			return -EBUSY;
 	}
 
-	gpio_desc_to_lineinfo(desc, &lineinfo_v2, false);
+	ret = gpio_desc_to_lineinfo(desc, &lineinfo_v2, false);
+	if (ret)
+		return ret;
+
 	gpio_v2_line_info_to_v1(&lineinfo_v2, &lineinfo);
 
 	if (copy_to_user(ip, &lineinfo, sizeof(lineinfo))) {
@@ -2346,6 +2353,7 @@ static int lineinfo_get(struct gpio_chardev_data *cdev, void __user *ip,
 {
 	struct gpio_desc *desc;
 	struct gpio_v2_line_info lineinfo;
+	int ret;
 
 	if (copy_from_user(&lineinfo, ip, sizeof(lineinfo)))
 		return -EFAULT;
@@ -2365,7 +2373,10 @@ static int lineinfo_get(struct gpio_chardev_data *cdev, void __user *ip,
 		if (test_and_set_bit(lineinfo.offset, cdev->watched_lines))
 			return -EBUSY;
 	}
-	gpio_desc_to_lineinfo(desc, &lineinfo, false);
+
+	ret = gpio_desc_to_lineinfo(desc, &lineinfo, false);
+	if (ret)
+		return ret;
 
 	if (copy_to_user(ip, &lineinfo, sizeof(lineinfo))) {
 		if (watch)
@@ -2491,6 +2502,7 @@ static int lineinfo_changed_notify(struct notifier_block *nb,
 	struct lineinfo_changed_ctx *ctx;
 	struct gpio_desc *desc = data;
 	struct file *fp;
+	int ret;
 
 	if (!test_bit(gpiod_hwgpio(desc), cdev->watched_lines))
 		return NOTIFY_DONE;
@@ -2521,7 +2533,14 @@ static int lineinfo_changed_notify(struct notifier_block *nb,
 
 	ctx->chg.event_type = action;
 	ctx->chg.timestamp_ns = ktime_get_ns();
-	gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
+
+	ret = gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
+	if (ret) {
+		fput(fp);
+		pr_err("GPIO controller that generated the line info notification was removed\n");
+		return NOTIFY_DONE;
+	}
+
 	/* Keep the GPIO device alive until we emit the event. */
 	ctx->gdev = gpio_device_get(desc->gdev);
 	ctx->cdev = cdev;

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

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

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

[Kent Gibson]

On Mon, Sep 21, 2026 at 02:56:58PM +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. Make gpio_desc_to_lineinfo() return int so that the
> -ENODEV returned on failure to acquire the guard can be propagated to
> the callers.
> 
> While not strictly necessary: move the memset() before trying to acquire
> the SRCU read lock too for good measure.
> 
> 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>
> ---
> Changes in v2:
> - Make gpio_desc_to_lineinfo() return an integer return value so that
>   the error code returned in case of a failure to acquire the guard can
>   be propagated down the stack
> - Link to v1: https://patch.msgid.link/20260917-gpio-cdev-stack-leak-fixes-v1-1-2bb52879e49c@oss.qualcomm.com

> @@ -2521,7 +2533,14 @@ static int lineinfo_changed_notify(struct notifier_block *nb,
>  
>  	ctx->chg.event_type = action;
>  	ctx->chg.timestamp_ns = ktime_get_ns();
> -	gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
> +
> +	ret = gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
> +	if (ret) {
> +		fput(fp);
> +		pr_err("GPIO controller that generated the line info notification was removed\n");
> +		return NOTIFY_DONE;
> +	}
> +

Does resolving a race warrant an error?

Also, compared to the kzalloc_obj() error path earlier in the function, here
you flip the order of the fput() and pr_err(). Is that significant?

Other than that, looks good to me.

Cheers,
Kent.

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

[Bartosz Golaszewski]

On Mon, 21 Sep 2026 15:35:05 +0200, Kent Gibson <warthog618@gmail.com> said:
> On Mon, Sep 21, 2026 at 02:56:58PM +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. Make gpio_desc_to_lineinfo() return int so that the
>> -ENODEV returned on failure to acquire the guard can be propagated to
>> the callers.
>>
>> While not strictly necessary: move the memset() before trying to acquire
>> the SRCU read lock too for good measure.
>>
>> 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>
>> ---
>> Changes in v2:
>> - Make gpio_desc_to_lineinfo() return an integer return value so that
>>   the error code returned in case of a failure to acquire the guard can
>>   be propagated down the stack
>> - Link to v1: https://patch.msgid.link/20260917-gpio-cdev-stack-leak-fixes-v1-1-2bb52879e49c@oss.qualcomm.com
>
>> @@ -2521,7 +2533,14 @@ static int lineinfo_changed_notify(struct notifier_block *nb,
>>
>>  	ctx->chg.event_type = action;
>>  	ctx->chg.timestamp_ns = ktime_get_ns();
>> -	gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
>> +
>> +	ret = gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
>> +	if (ret) {
>> +		fput(fp);
>> +		pr_err("GPIO controller that generated the line info notification was removed\n");
>> +		return NOTIFY_DONE;
>> +	}
>> +
>
> Does resolving a race warrant an error?
>

I guess not, we can just not do anything in this case.

> Also, compared to the kzalloc_obj() error path earlier in the function, here
> you flip the order of the fput() and pr_err(). Is that significant?
>

No, if anything this version is more correct as we drop the no-longer-needed
resource before printing a log. But with the above it's irrelevant anyway.

Bart

> Other than that, looks good to me.
>
> Cheers,
> Kent.
>

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

[Kent Gibson]

On Mon, Sep 21, 2026 at 10:51:42AM -0400, Bartosz Golaszewski wrote:
> On Mon, 21 Sep 2026 15:35:05 +0200, Kent Gibson <warthog618@gmail.com> said:
> > On Mon, Sep 21, 2026 at 02:56:58PM +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. Make gpio_desc_to_lineinfo() return int so that the
> >> -ENODEV returned on failure to acquire the guard can be propagated to
> >> the callers.
> >>
> >> While not strictly necessary: move the memset() before trying to acquire
> >> the SRCU read lock too for good measure.
> >>
> >> 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>
> >> ---
> >> Changes in v2:
> >> - Make gpio_desc_to_lineinfo() return an integer return value so that
> >>   the error code returned in case of a failure to acquire the guard can
> >>   be propagated down the stack
> >> - Link to v1: https://patch.msgid.link/20260917-gpio-cdev-stack-leak-fixes-v1-1-2bb52879e49c@oss.qualcomm.com
> >
> >> @@ -2521,7 +2533,14 @@ static int lineinfo_changed_notify(struct notifier_block *nb,
> >>
> >>  	ctx->chg.event_type = action;
> >>  	ctx->chg.timestamp_ns = ktime_get_ns();
> >> -	gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
> >> +
> >> +	ret = gpio_desc_to_lineinfo(desc, &ctx->chg.info, true);
> >> +	if (ret) {
> >> +		fput(fp);
> >> +		pr_err("GPIO controller that generated the line info notification was removed\n");
> >> +		return NOTIFY_DONE;
> >> +	}
> >> +
> >
> > Does resolving a race warrant an error?
> >
> 
> I guess not, we can just not do anything in this case.
> 

You could log a debug rather than an error, but I'm not sure that adds anything
- I have no problem with quietly discarding the notify if the chip has been
removed.

> > Also, compared to the kzalloc_obj() error path earlier in the function, here
> > you flip the order of the fput() and pr_err(). Is that significant?
> >
> 
> No, if anything this version is more correct as we drop the no-longer-needed
> resource before printing a log. But with the above it's irrelevant anyway.
>

I was thinking the same, and wondering if we should flip the other case, but
small potatoes and not part of this patch.

Cheers,
Kent,