linux-kernel - [PATCH 5.10 64/80] driver core: Dont probe devices after bus

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: <20220906132819.737567417@linuxfoundation.org>
Date:   Tue,  6 Sep 2022 15:31:01 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Saravana Kannan <saravanak@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Linus Walleij <linus.walleij@...aro.org>,
        "Isaac J. Manjarres" <isaacmanjarres@...gle.com>
Subject: [PATCH 5.10 64/80] driver core: Dont probe devices after bus_type.match() probe deferral

From: Isaac J. Manjarres <isaacmanjarres@...gle.com>

commit 25e9fbf0fd38868a429feabc38abebfc6dbf6542 upstream.

Both __device_attach_driver() and __driver_attach() check the return
code of the bus_type.match() function to see if the device needs to be
added to the deferred probe list. After adding the device to the list,
the logic attempts to bind the device to the driver anyway, as if the
device had matched with the driver, which is not correct.

If __device_attach_driver() detects that the device in question is not
ready to match with a driver on the bus, then it doesn't make sense for
the device to attempt to bind with the current driver or continue
attempting to match with any of the other drivers on the bus. So, update
the logic in __device_attach_driver() to reflect this.

If __driver_attach() detects that a driver tried to match with a device
that is not ready to match yet, then the driver should not attempt to bind
with the device. However, the driver can still attempt to match and bind
with other devices on the bus, as drivers can be bound to multiple
devices. So, update the logic in __driver_attach() to reflect this.

Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable@...r.kernel.org
Cc: Saravana Kannan <saravanak@...gle.com>
Reported-by: Guenter Roeck <linux@...ck-us.net>
Tested-by: Guenter Roeck <linux@...ck-us.net>
Tested-by: Linus Walleij <linus.walleij@...aro.org>
Reviewed-by: Saravana Kannan <saravanak@...gle.com>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@...gle.com>
Link: https://lore.kernel.org/r/20220817184026.3468620-1-isaacmanjarres@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 drivers/base/dd.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -837,6 +837,11 @@ static int __device_attach_driver(struct
 	} else if (ret == -EPROBE_DEFER) {
 		dev_dbg(dev, "Device match requests probe deferral\n");
 		driver_deferred_probe_add(dev);
+		/*
+		 * Device can't match with a driver right now, so don't attempt
+		 * to match or bind with other drivers on the bus.
+		 */
+		return ret;
 	} else if (ret < 0) {
 		dev_dbg(dev, "Bus failed to match device: %d\n", ret);
 		return ret;
@@ -1076,6 +1081,11 @@ static int __driver_attach(struct device
 	} else if (ret == -EPROBE_DEFER) {
 		dev_dbg(dev, "Device match requests probe deferral\n");
 		driver_deferred_probe_add(dev);
+		/*
+		 * Driver could not match with device, but may match with
+		 * another device on the bus.
+		 */
+		return 0;
 	} else if (ret < 0) {
 		dev_dbg(dev, "Bus failed to match device: %d\n", ret);
 		return ret;