linux-kernel - [PATCH 3.16.y-ckt 059/133] drivercore: Fix unregistration path of platform devices

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: <1443606681-7124-60-git-send-email-luis.henriques@canonical.com>
Date:	Wed, 30 Sep 2015 10:50:07 +0100
From:	Luis Henriques <luis.henriques@...onical.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com
Cc:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	Rob Herring <robh@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Luis Henriques <luis.henriques@...onical.com>
Subject: [PATCH 3.16.y-ckt 059/133] drivercore: Fix unregistration path of platform devices

3.16.7-ckt18 -stable review patch.  If anyone has any objections, please let me know.

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

From: Grant Likely <grant.likely@...aro.org>

commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 upstream.

The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.

Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.

* It can be argued that of_platform_populate() should be registering
  it's resources, and they argument has some merit. However, there are
  quite a few platforms that end up broken if we try to do that due to
  overlapping resources in the device tree. Until that is fixed, we need
  to solve the immediate problem.

Cc: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc: Wolfram Sang <wsa@...-dreams.de>
Cc: Rob Herring <robh@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Signed-off-by: Grant Likely <grant.likely@...aro.org>
Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Tested-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
Signed-off-by: Rob Herring <robh@...nel.org>
Signed-off-by: Luis Henriques <luis.henriques@...onical.com>
---
 drivers/base/platform.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index eee48c49f5de..9106f3046569 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -362,9 +362,7 @@ int platform_device_add(struct platform_device *pdev)

 	while (--i >= 0) {
 		struct resource *r = &pdev->resource[i];
-		unsigned long type = resource_type(r);
-
-		if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
+		if (r->parent)
 			release_resource(r);
 	}

@@ -395,9 +393,7 @@ void platform_device_del(struct platform_device *pdev)

 		for (i = 0; i < pdev->num_resources; i++) {
 			struct resource *r = &pdev->resource[i];
-			unsigned long type = resource_type(r);
-
-			if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
+			if (r->parent)
 				release_resource(r);
 		}
 	}
--
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/