linux-stable.git/drivers/base/firmware_class.c, branch linux-3.14.y

Fix firmware loader uevent buffer NULL pointer dereference

2015-08-03T16:29:59+00:00

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

firmware_class: make sure fw requests contain a name

2014-10-30T16:38:20+00:00

commit 471b095dfe0d693a8d624cbc716d1ee4d74eb437 upstream.

An empty firmware request name will trigger warnings when building
device names. Make sure this is caught earlier and rejected.

The warning was visible via the test_firmware.ko module interface:

echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request

Reported-by: Sasha Levin 
Signed-off-by: Kees Cook 
Tested-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PM / hibernate: Fix restore hang in freeze_processes()

2014-02-26T00:13:15+00:00

During restore, pm_notifier chain are called with
PM_RESTORE_PREPARE.  The firmware_class driver handler
fw_pm_notify does not have a handler for this.  As a result,
it keeps a reader on the kmod.c umhelper_sem.  During
freeze_processes, the call to __usermodehelper_disable tries to
take a write lock on this semaphore and hangs waiting.

Signed-off-by: Sebastian Capella 
Acked-by: Ming Lei 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

firmware_class: Fix the file size check

2014-01-09T04:29:19+00:00

We expect to read firmware blobs with a single call to kernel_read(),
which returns int.  Therefore the size must be within the range of
int, not long.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

firmware loader: Add sparse annotation

2014-01-08T23:36:18+00:00

Avoid that sparse reports the following warning on __fw_free_buf():

drivers/base/firmware_class.c:230:9: warning: context imbalance in '__fw_free_buf' - unexpected unlock

Signed-off-by: Bart Van Assche 
Acked-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware: Suppress fallback warnings when CONFIG_FW_LOADER_USER_HELPER=n

2013-12-09T02:22:33+00:00

The commit [3e358ac2bb5b: firmware: Be a bit more verbose about direct
firmware loading failure] introduced a new warning message about
falling back to user helper, but this isn't true when
CONFIG_FW_LOADER_USER_HELPER isn't set.

In this patch, clear the FW_OPT_FALLBACK flag in the case without
userhelper, so that the corresponding code will be disabled.

Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

firmware: Use bit flags instead of boolean combos

2013-12-09T02:22:32+00:00

More than two boolean arguments to a function are rather confusing and
error-prone for callers.  Let's make the behavior bit flags instead of
triple combos.

A nice suggestion by Borislav Petkov.

Acked-by: Borislav Petkov 
Acked-by: Prarit Bhargava 
Acked-by: Ming Lei 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

firmware: Introduce request_firmware_direct()

2013-12-09T02:22:32+00:00

When CONFIG_FW_LOADER_USER_HELPER is set, request_firmware() falls
back to the usermode helper for loading via udev when the direct
loading fails.  But the recent udev takes way too long timeout (60
seconds) for non-existing firmware.  This is unacceptable for the
drivers like microcode loader where they load firmwares optionally,
i.e. it's no error even if no requested file exists.

This patch provides a new helper function, request_firmware_direct().
It behaves as same as request_firmware() except for that it doesn't
fall back to usermode helper but returns an error immediately if the
f/w can't be loaded directly in kernel.

Without CONFIG_FW_LOADER_USER_HELPER=y, request_firmware_direct() is
just an alias of request_firmware(), due to obvious reason.

Tested-by: Prarit Bhargava 
Acked-by: Ming Lei 
Acked-by: Borislav Petkov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

firmware: Be a bit more verbose about direct firmware loading failure

2013-09-26T22:35:30+00:00

The direct firmware loading interface is a bit quiet about failures.  Failures
that occur during loading are masked if firmware exists in multiple locations,
and may be masked entirely in the event that we fall back to the user mode
helper code.  It would be nice to see some of the more unexpected errors get
logged, so in the event that you expect the direct firmware loader to work (like
if CONFIG_FW_LOADER_USER_HELPER is enabled), and something goes wrong, you can
figure out what happened.

Signed-off-by: Neil Horman 
Acked-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware loader: fix pending_fw_head list corruption

2013-08-30T19:04:27+00:00

Got the following oops just before reboot:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
[<8028d300>] (__list_del_entry+0x44/0xac)
[<802e3320>] (__fw_load_abort.part.13+0x1c/0x50)
[<802e337c>] (fw_shutdown_notify+0x28/0x50)
[<80034f80>] (notifier_call_chain.isra.1+0x5c/0x9c)
[<800350ec>] (__blocking_notifier_call_chain+0x44/0x58)
[<80035114>] (blocking_notifier_call_chain+0x14/0x18)
[<80035d64>] (kernel_restart_prepare+0x14/0x38)
[<80035d94>] (kernel_restart+0xc/0x50)

The following race condition triggers here:

  _request_firmware_load()
  device_create_file(...)
  kobject_uevent(...)
  (schedule)
                                       (resume)
                                       firmware_loading_store(1)
                                       firmware_loading_store(0)
                                       list_del_init(&buf->pending_list)
                                       (schedule)
  (resume)
  list_add(&buf->pending_list, &pending_fw_head);
  wait_for_completion(&buf->completion);

causing an oops later when walking pending_list after the firmware has
been released.

The proposed fix is to move the list_add() before sysfs attribute
creation.

Signed-off-by: Maxime Bizon 
Acked-by: Ming Lei 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman