kernel/drivers/base/firmware_class.c, branch linux-4.1.y

firmware: fix usermode helper fallback loading

2017-01-13T01:56:54Z

[ Upstream commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 ] When you use the firmware usermode helper fallback with a timeout value set to a value greater than INT_MAX (2147483647) a cast overflow issue causes the timeout value to go negative and breaks all usermode helper loading. This regression was introduced through commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") on kernel v4.0. The firmware_class drivers relies on the firmware usermode helper fallback as a mechanism to look for firmware if the direct filesystem search failed only if: a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros): Then all of these callers will rely on the fallback mechanism in case the firmware is not found through an initial direct filesystem lookup: o request_firmware() o request_firmware_into_buf() o request_firmware_nowait() b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros): Then only callers using request_firmware_nowait() with the second argument set to false, this explicitly is requesting the UMH firmware fallback to be relied on in case the first filesystem lookup fails. Using Coccinelle SmPL grammar we have identified only two drivers explicitly requesting the UMH firmware fallback mechanism: - drivers/firmware/dell_rbu.c - drivers/leds/leds-lp55xx-common.c Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the biggest impact of this regression are users of the dell_rbu and leds-lp55xx-common device driver which required the UMH to find their respective needed firmwares. The default timeout for the UMH is set to 60 seconds always, as of commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") the timeout was bumped to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET value was also used if the timeout was configured by a user to 0. The following works: echo 2147483647 > /sys/class/firmware/timeout But both of the following set the timeout to MAX_JIFFY_OFFSET even if we display 0 back to userspace: echo 2147483648 > /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 echo 0> /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 A max value of INT_MAX (2147483647) seconds is therefore implicit due to the another cast with simple_strtol(). This fixes the secondary cast (the first one is simple_strtol() but its an issue only by forcing an implicit limit) by re-using the timeout variable and only setting retval in appropriate cases. Lastly worth noting systemd had ripped out the UMH firmware fallback mechanism from udev since udev 2014 via commit be2ea723b1d023b3d ("udev: remove userspace firmware loading support"), so as of systemd v217. Signed-off-by: Yves-Alexis Perez Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" Cc: Luis R. Rodriguez Cc: Ming Lei Cc: Bjorn Andersson Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org Acked-by: Luis R. Rodriguez Reviewed-by: Bjorn Andersson [mcgrof@kernel.org: gave commit log a whole lot of love] Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Fix firmware loader uevent buffer NULL pointer dereference

2015-08-03T16:29:19Z

commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream. The firmware class uevent function accessed the "fw_priv->buf" buffer without the proper locking and testing for NULL. This is an old bug (looks like it goes back to 2012 and commit 1244691c73b2: "firmware loader: introduce firmware_buf"), but for some reason it's triggering only now in 4.2-rc1. Shuah Khan is trying to bisect what it is that causes this to trigger more easily, but in the meantime let's just fix the bug since others are hitting it too (at least Ingo reports having seen it as well). Reported-and-tested-by: Shuah Khan Acked-by: Ming Lei Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drivers: base: fw: fix ret value when loading fw

2015-03-25T13:49:10Z

When using the user mode helper to load firmwares the function _request_firmware gets a positive return value from fw_load_from_user_helper and because of this the firmware buffer is not assigned. This happens only when the return value is zero. This patch fixes this problem in _request_firmware_load. When the completion is ready the return value is set to zero. Signed-off-by: Zahari Doychev Cc: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware: Avoid manual device_create_file() calls

2015-03-25T13:41:48Z

Use the static attribute groups assigned to the device instead of manual device_create_file() & co calls. It simplifies the code and can avoid possible races, too. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

firmware_class: Fix whitespace and indentation

2015-03-25T13:36:19Z

Fix checkpatch.pl issues with coding style. Removed whitespace and fixed indentation Signed-off-by: Andrei Oprea Signed-off-by: Greg Kroah-Hartman

Merge tag 'driver-core-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2015-02-15T19:11:47Z

Pull driver core patches from Greg KH: "Really tiny set of patches for this kernel. Nothing major, all described in the shortlog and have been in linux-next for a while" * tag 'driver-core-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: sysfs: fix warning when creating a sysfs group without attributes firmware_loader: handle timeout via wait_for_completion_interruptible_timeout() firmware_loader: abort request if wait_for_completion is interrupted firmware: Correct function name in comment device: Change dev_ logging functions to return void device: Fix dev_dbg_once macro

PM / OPP / clk: Remove unnecessary OOM message

2015-02-12T01:00:52Z

This patch reduces the kernel size by removing error messages that duplicate the normal OOM message. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr) @@ identifier f,print,l; expression e; constant char[] c; @@ e = \(kzalloc\|kmalloc\|devm_kzalloc\|devm_kmalloc\)(...); if (e == NULL) { <+... - print(...,c,...); ... when any ( goto l; | return ...; ) ...+> } Signed-off-by: Quentin Lambert Acked-by: Nishanth Menon Signed-off-by: Rafael J. Wysocki

firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()

2015-02-03T23:33:10Z

It is simpler to handle timeout by wait_for_completion_interruptible_timeout(), so remove previous delay work for timeout. Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware_loader: abort request if wait_for_completion is interrupted

2015-02-03T23:33:10Z

If current request is interrupted by signal, such as 'ctrl + c', this request has to be aborted for the following reasons: - the buf need to be removed from pending list - same requests from other contexts need to be completed Reported-by: Sasha Levin Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware: Correct function name in comment

2015-02-03T23:32:18Z

Use the correct function name in the kernel-doc comment above it. Signed-off-by: Borislav Petkov Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman