linux-kernel - Re: [PATCH] gpio: cdev: check for NULL labels when sanitizing them for irqs

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: <20240403094205.GA158151@rigel>
Date: Wed, 3 Apr 2024 17:42:05 +0800
From: Kent Gibson <warthog618@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>,
	stable@...r.kernel.org, Stefan Wahren <wahrenst@....net>,
	Naresh Kamboju <naresh.kamboju@...aro.org>,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
	Linux Kernel Functional Testing <lkft@...aro.org>
Subject: Re: [PATCH] gpio: cdev: check for NULL labels when sanitizing them
 for irqs

On Tue, Apr 02, 2024 at 01:41:59PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>
> We need to take into account that a line's consumer label may be NULL
> and not try to kstrdup() it in that case but rather pass the NULL
> pointer up the stack to the interrupt request function.
>
> To that end: let make_irq_label() return NULL as a valid return value
> and use ERR_PTR() instead to signal an allocation failure to callers.
>
> Cc: stable@...r.kernel.org
> Fixes: b34490879baa ("gpio: cdev: sanitize the label before requesting the interrupt")
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> Closes: https://lore.kernel.org/lkml/20240402093534.212283-1-naresh.kamboju@linaro.org/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> ---
>  drivers/gpio/gpiolib-cdev.c | 19 ++++++++++++++-----
>  1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index fa9635610251..1426cc1c4a28 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -1085,7 +1085,16 @@ static u32 gpio_v2_line_config_debounce_period(struct gpio_v2_line_config *lc,
>
>  static inline char *make_irq_label(const char *orig)
>  {
> -	return kstrdup_and_replace(orig, '/', ':', GFP_KERNEL);
> +	char *new;
> +
> +	if (!orig)
> +		return NULL;
> +
> +	new = kstrdup_and_replace(orig, '/', ':', GFP_KERNEL);
> +	if (!new)
> +		return ERR_PTR(-ENOMEM);
> +
> +	return new;
>  }
>
>  static inline void free_irq_label(const char *label)
> @@ -1158,8 +1167,8 @@ static int edge_detector_setup(struct line *line,
>  	irqflags |= IRQF_ONESHOT;
>
>  	label = make_irq_label(line->req->label);
> -	if (!label)
> -		return -ENOMEM;
> +	if (IS_ERR(label))
> +		return PTR_ERR(label);
>
>  	/* Request a thread to read the events */
>  	ret = request_threaded_irq(irq, edge_irq_handler, edge_irq_thread,
> @@ -2217,8 +2226,8 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip)
>  		goto out_free_le;
>
>  	label = make_irq_label(le->label);
> -	if (!label) {
> -		ret = -ENOMEM;
> +	if (IS_ERR(label)) {
> +		ret = PTR_ERR(label);
>  		goto out_free_le;
>  	}
>

It occurred to me that none of my tests cover this case, as they always
request edges with the consumer set, so I added some and can confirm both
the problem and the fix.

In the process I found another bug - we overlooked setting up the irq
label in debounce_setup() - the alternate path in edge_detector_setup()
that performs sw debounce.  That results in a double free of the
req->label and memory corruption hilarity follows.

I've got a patch for that - the unfortunate part being that
debounce_setup() is earlier in the file than make_irq_label() and
free_irq_label().  Those will need to be pushed earlier, so it is
sure to conflict with this patch.
How would you prefer to proceed?

Cheers,
Kent.