linux-kernel - Re: [PATCH] gpiolib: fix invalid pointer access in debugfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2f6730c4-74f9-4c07-a30a-11d6fdcb1b83@gmail.com>
Date: Sat, 1 Nov 2025 11:55:54 +0300
From: Ilya Gavrilov <ilyagv@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>,
 Linus Walleij <linus.walleij@...aro.org>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH] gpiolib: fix invalid pointer access in debugfs

Hi Bartosz,

On 10/31/25 18:06, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> 
> If the memory allocation in gpiolib_seq_start() fails, the s->private
> field remains uninitialized and is later dereferenced without checking
> in gpiolib_seq_stop(). Initialize s->private to NULL before calling
> kzalloc() and check it before dereferencing it.
> 
> Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU")
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> ---
> This was brought to my attention by a person under sanctions. This is a
> simplified version of their initial patch.
> 
>  drivers/gpio/gpiolib.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a81981336b36..fdb6a002dbda 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -5303,6 +5303,8 @@ static void *gpiolib_seq_start(struct seq_file *s, loff_t *pos)
>  	struct gpio_device *gdev;
>  	loff_t index = *pos;
>  
> +	s->private = NULL;
> +
>  	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>  	if (!priv)
>  		return NULL;
> @@ -5338,6 +5340,9 @@ static void gpiolib_seq_stop(struct seq_file *s, void *v)
>  {
>  	struct gpiolib_seq_priv *priv = s->private;
>  
> +	if (!priv)
> +		return;
> +
>  	srcu_read_unlock(&gpio_devices_srcu, priv->idx);
>  	kfree(priv);
>  }

Maybe in this case it is better to signal an error and
explicitly return ERR_PTR(-ENOMEM) in gpiolib_seq_start(), rather than ignore it?