linux-kernel - [PATCH 3.2 069/164] gpio: sysfs: fix memory leaks and device hotplug

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]

Date:	Sun, 02 Aug 2015 01:02:37 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:	akpm@...ux-foundation.org,
	"Linus Walleij" <linus.walleij@...aro.org>,
	"Johan Hovold" <johan@...nel.org>
Subject: [PATCH 3.2 069/164] gpio: sysfs: fix memory leaks and device hotplug

3.2.70-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Johan Hovold <johan@...nel.org>

commit 483d821108791092798f5d230686868112927044 upstream.

Unregister GPIOs requested through sysfs at chip remove to avoid leaking
the associated memory and sysfs entries.

The stale sysfs entries prevented the gpio numbers from being exported
when the gpio range was later reused (e.g. at device reconnect).

This also fixes the related module-reference leak.

Note that kernfs makes sure that any on-going sysfs operations finish
before the class devices are unregistered and that further accesses
fail.

The chip exported flag is used to prevent gpiod exports during removal.
This also makes it harder to trigger, but does not fix, the related race
between gpiochip_remove and export_store, which is really a race with
gpiod_request that needs to be addressed separately.

Also note that this would prevent the crashes (e.g. NULL-dereferences)
at reconnect that affects pre-3.18 kernels, as well as use-after-free on
operations on open attribute files on pre-3.14 kernels (prior to
kernfs).

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@...nel.org>
Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Move up initialisation of 'desc' in gpio_export()
 - Use global 'gpio_desc' array and gpio_free() function in
   gpiochip_unexport()]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -726,6 +726,7 @@ static struct class gpio_class = {
  */
 int gpio_export(unsigned gpio, bool direction_may_change)
 {
+	struct gpio_chip	*chip;
 	unsigned long		flags;
 	struct gpio_desc	*desc;
 	int			status;
@@ -743,10 +744,18 @@ int gpio_export(unsigned gpio, bool dire
 		return -EINVAL;
 	}
 
+	desc = &gpio_desc[gpio];
+	chip = desc->chip;
+
 	mutex_lock(&sysfs_lock);
 
+	/* check if chip is being removed */
+	if (!chip || !chip->exported) {
+		status = -ENODEV;
+		goto fail_unlock;
+	}
+
 	spin_lock_irqsave(&gpio_lock, flags);
-	desc = &gpio_desc[gpio];
 	if (!test_bit(FLAG_REQUESTED, &desc->flags) ||
 	     test_bit(FLAG_EXPORT, &desc->flags)) {
 		spin_unlock_irqrestore(&gpio_lock, flags);
@@ -973,12 +982,15 @@ static void gpiochip_unexport(struct gpi
 {
 	int			status;
 	struct device		*dev;
+	struct gpio_desc *desc;
+	unsigned int i;
 
 	mutex_lock(&sysfs_lock);
 	dev = class_find_device(&gpio_class, NULL, chip, match_export);
 	if (dev) {
 		put_device(dev);
 		device_unregister(dev);
+		/* prevent further gpiod exports */
 		chip->exported = 0;
 		status = 0;
 	} else
@@ -988,6 +1000,13 @@ static void gpiochip_unexport(struct gpi
 	if (status)
 		pr_debug("%s: chip %s status %d\n", __func__,
 				chip->label, status);
+
+	/* unregister gpio class devices owned by sysfs */
+	for (i = 0; i < chip->ngpio; i++) {
+		desc = &gpio_desc[chip->base + i];
+		if (test_and_clear_bit(FLAG_SYSFS, &desc->flags))
+			gpio_free(chip->base + i);
+	}
 }
 
 static int __init gpiolib_sysfs_init(void)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/