linux-kernel - [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 25 Apr 2016 23:57:32 -0500
From:	Mario Limonciello <mario_limonciello@...l.com>
To:	ming.lei@...onical.com
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mario Limonciello <mario_limonciello@...l.com>,
	stable@...r.kernel.org, stuart_hayes@...l.com
Subject: [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

Before this commit both code paths (hotplug and not-hotplug as determined
by FW_OPT_UEVENT)  would block on an interruptible completion, but the
hotplugscenario also would wait until timeout and then abort.  The non
hotplugscenario (which dell-rbu followed) would block indefinitely until
interrupted.

After this commit both scenarios block on an interruptible condition but
the hotplug scenario follows the value of firmware_loading_timeout to end.
This changed the situation for the non hotplug scenario to instead wait
for MAX_JIFFY_OFFSET.  This should have the same result, but dell-rbu was
failing with negative values returned from
wait_for_completion_interruptible_timeout after completion occurred.

This shouldn't be possible, but it was happening because the return is a
long but the value it was being saved to was an int.  When completion
occurs quickly wait_for_completion_interruptible_timeout returns how much
time was left (which happens to be a very big number since the timeout was
MAX_JIFFY_OFFSET) One test run of mine returned 4611686018427368747.

Other parts of the kernel with this type of return don't have problems
because they use smaller timeouts.

So to fix this: change the test to not store the value to an int, but
rather directly compare against what
wait_for_completion_interruptible_timeout can return.

Fixes: 68ff2a00dbf59 (firmware_loader: handle timeout via wait_for_completion_interruptible_timeout())
CC: stable@...r.kernel.org
CC: stuart_hayes@...l.com
Signed-off-by: Mario Limonciello <mario_limonciello@...l.com>
---
 drivers/base/firmware_class.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc30..223af70 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -917,14 +917,11 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
 		timeout = MAX_JIFFY_OFFSET;
 	}

-	retval = wait_for_completion_interruptible_timeout(&buf->completion,
-			timeout);
-	if (retval == -ERESTARTSYS || !retval) {
+	if (wait_for_completion_interruptible_timeout(&buf->completion,
+						timeout) <= 0) {
 		mutex_lock(&fw_lock);
 		fw_load_abort(fw_priv);
 		mutex_unlock(&fw_lock);
-	} else if (retval > 0) {
-		retval = 0;
 	}

 	if (is_fw_load_aborted(buf))
-- 
2.7.4