linux-stable.git/drivers/firmware, branch v5.4.223 Linux kernel stable tree efi: libstub: drop pointless get_memory_map() call 2022-10-26T11:23:00+00:00 Ard Biesheuvel ardb@kernel.org 2022-09-15T17:00:24+00:00 96e2e21284ca4b1153fbc71811a3022ffa2850e5 commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream. Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream.

Currently, the non-x86 stub code calls get_memory_map() redundantly,
given that the data it returns is never used anywhere. So drop the call.

Cc: <stable@vger.kernel.org> # v4.14+
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: google: Test spinlock on panic path to avoid lockups 2022-10-26T11:22:40+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-09-09T20:07:55+00:00 c969316eeefb0726552c89ae96ea0de56604ccbd [ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ] Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown. With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang. Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: David Gow <davidgow@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Petr Mladek <pmladek@suse.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]

Currently the gsmi driver registers a panic notifier as well as
reboot and die notifiers. The callbacks registered are called in
atomic and very limited context - for instance, panic disables
preemption and local IRQs, also all secondary CPUs (not executing
the panic path) are shutdown.

With that said, taking a spinlock in this scenario is a dangerous
invitation for lockup scenarios. So, fix that by checking if the
spinlock is free to acquire in the panic notifier callback - if not,
bail-out and avoid a potential hang.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: David Gow <davidgow@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Petr Mladek <pmladek@suse.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: arm_scmi: Add SCMI PM driver remove routine 2022-10-15T05:54:37+00:00 Cristian Marussi cristian.marussi@arm.com 2022-08-17T17:27:31+00:00 59684c877783b81d2ee8cff6585da1e94232b16a [ Upstream commit dea796fcab0a219830831c070b8dc367d7e0f708 ] Currently, when removing the SCMI PM driver not all the resources registered with genpd subsystem are properly de-registered. As a side effect of this after a driver unload/load cycle you get a splat with a few warnings like this: | debugfs: Directory 'BIG_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU2' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU3' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'DBGSYS' with parent 'pm_genpd' already present! | debugfs: Directory 'GPUTOP' with parent 'pm_genpd' already present! Add a proper scmi_pm_domain_remove callback to the driver in order to take care of all the needed cleanups not handled by devres framework. Link: https://lore.kernel.org/r/20220817172731.1185305-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit dea796fcab0a219830831c070b8dc367d7e0f708 ]

Currently, when removing the SCMI PM driver not all the resources
registered with genpd subsystem are properly de-registered.

As a side effect of this after a driver unload/load cycle you get a
splat with a few warnings like this:

 | debugfs: Directory 'BIG_CPU0' with parent 'pm_genpd' already present!
 | debugfs: Directory 'BIG_CPU1' with parent 'pm_genpd' already present!
 | debugfs: Directory 'LITTLE_CPU0' with parent 'pm_genpd' already present!
 | debugfs: Directory 'LITTLE_CPU1' with parent 'pm_genpd' already present!
 | debugfs: Directory 'LITTLE_CPU2' with parent 'pm_genpd' already present!
 | debugfs: Directory 'LITTLE_CPU3' with parent 'pm_genpd' already present!
 | debugfs: Directory 'BIG_SSTOP' with parent 'pm_genpd' already present!
 | debugfs: Directory 'LITTLE_SSTOP' with parent 'pm_genpd' already present!
 | debugfs: Directory 'DBGSYS' with parent 'pm_genpd' already present!
 | debugfs: Directory 'GPUTOP' with parent 'pm_genpd' already present!

Add a proper scmi_pm_domain_remove callback to the driver in order to
take care of all the needed cleanups not handled by devres framework.

Link: https://lore.kernel.org/r/20220817172731.1185305-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
efi: libstub: check Shim mode using MokSBStateRT 2022-09-28T09:04:04+00:00 Ard Biesheuvel ardb@kernel.org 2022-09-20T15:08:23+00:00 cafb9cad9bcc4ff89e8e7a25db1f72ab51e42960 commit 5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 upstream. We currently check the MokSBState variable to decide whether we should treat UEFI secure boot as being disabled, even if the firmware thinks otherwise. This is used by shim to indicate that it is not checking signatures on boot images. In the kernel, we use this to relax lockdown policies. However, in cases where shim is not even being used, we don't want this variable to interfere with lockdown, given that the variable may be non-volatile and therefore persist across a reboot. This means setting it once will persistently disable lockdown checks on a given system. So switch to the mirrored version of this variable, called MokSBStateRT, which is supposed to be volatile, and this is something we can check. Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 upstream.

We currently check the MokSBState variable to decide whether we should
treat UEFI secure boot as being disabled, even if the firmware thinks
otherwise. This is used by shim to indicate that it is not checking
signatures on boot images. In the kernel, we use this to relax lockdown
policies.

However, in cases where shim is not even being used, we don't want this
variable to interfere with lockdown, given that the variable may be
non-volatile and therefore persist across a reboot. This means setting
it once will persistently disable lockdown checks on a given system.

So switch to the mirrored version of this variable, called MokSBStateRT,
which is supposed to be volatile, and this is something we can check.

Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
efi: capsule-loader: Fix use-after-free in efi_capsule_write 2022-09-15T10:04:49+00:00 Hyunwoo Kim imv4bel@gmail.com 2022-09-07T16:07:14+00:00 8028ff4cdbb3f20d3c1c04be33a83bab0cb94997 commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream. A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream.

A race condition may occur if the user calls close() on another thread
during a write() operation on the device node of the efi capsule.

This is a race condition that occurs between the efi_capsule_write() and
efi_capsule_flush() functions of efi_capsule_fops, which ultimately
results in UAF.

So, the page freeing process is modified to be done in
efi_capsule_release() instead of efi_capsule_flush().

Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails 2022-08-25T09:18:15+00:00 Sudeep Holla sudeep.holla@arm.com 2022-07-01T16:03:10+00:00 18048cba444a7c41dbf42c180d6b46606fc24c51 commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 upstream. When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. Link: https://lore.kernel.org/r/20220701160310.148344-1-sudeep.holla@arm.com Cc: stable@vger.kernel.org # 4.19+ Reported-by: huhai <huhai@kylinos.cn> Reviewed-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 upstream.

When scpi probe fails, at any point, we need to ensure that the scpi_info
is not set and will remain NULL until the probe succeeds. If it is not
taken care, then it could result use-after-free as the value is exported
via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
but freed when the probe fails.

Link: https://lore.kernel.org/r/20220701160310.148344-1-sudeep.holla@arm.com
Cc: stable@vger.kernel.org # 4.19+
Reported-by: huhai <huhai@kylinos.cn>
Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle 2022-06-14T16:11:54+00:00 Miaoqian Lin linmq006@gmail.com 2022-05-11T07:14:19+00:00 a724634b2a49f6ff0177a9e19a5a92fc1545e1b7 [ Upstream commit 660ba678f9998aca6db74f2dd912fa5124f0fa31 ] kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put(). Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220511071421.9769-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 660ba678f9998aca6db74f2dd912fa5124f0fa31 ]

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()

   If this function returns an error, kobject_put() must be called to
   properly clean up the memory associated with the object.

Fix this issue by calling kobject_put().

Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220511071421.9769-1-linmq006@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: stratix10-svc: fix a missing check on list iterator 2022-06-14T16:11:52+00:00 Xiaomeng Tong xiam0nd.tong@gmail.com 2022-04-14T03:56:09+00:00 bec18bb00f11fe75ac1156c3bc3cccd7c6e825b6 [ Upstream commit 5a0793ac66ac0e254d292f129a4d6c526f9f2aff ] The bug is here: pmem->vaddr = NULL; The list iterator 'pmem' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix this bug, just gen_pool_free/set NULL/list_del() and return when found, otherwise list_del HEAD and return; Fixes: 7ca5ce896524f ("firmware: add Intel Stratix10 service layer driver") Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Link: https://lore.kernel.org/r/20220414035609.2239-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5a0793ac66ac0e254d292f129a4d6c526f9f2aff ]

The bug is here:
	pmem->vaddr = NULL;

The list iterator 'pmem' will point to a bogus position containing
HEAD if the list is empty or no element is found. This case must
be checked before any use of the iterator, otherwise it will
lead to a invalid memory access.

To fix this bug, just gen_pool_free/set NULL/list_del() and return
when found, otherwise list_del HEAD and return;

Fixes: 7ca5ce896524f ("firmware: add Intel Stratix10 service layer driver")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Link: https://lore.kernel.org/r/20220414035609.2239-1-xiam0nd.tong@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: arm_scmi: Fix list protocols enumeration in the base protocol 2022-06-14T16:11:40+00:00 Cristian Marussi cristian.marussi@arm.com 2022-03-30T15:05:32+00:00 b0e4bafac8963c2d85ee18d3d01f393735acceec [ Upstream commit 8009120e0354a67068e920eb10dce532391361d0 ] While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition. Link: https://lore.kernel.org/r/20220330150551.2573938-4-cristian.marussi@arm.com Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8009120e0354a67068e920eb10dce532391361d0 ]

While enumerating protocols implemented by the SCMI platform using
BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is
currently validated in an improper way since the check employs a sum
between unsigned integers that could overflow and cause the check itself
to be silently bypassed if the returned value 'loop_num_ret' is big
enough.

Fix the validation avoiding the addition.

Link: https://lore.kernel.org/r/20220330150551.2573938-4-cristian.marussi@arm.com
Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: google: Properly state IOMEM dependency 2022-04-15T12:18:20+00:00 David Gow davidgow@google.com 2022-02-25T04:15:02+00:00 1bb231de81fced226db5b610c07f0fc9f149189f [ Upstream commit 37fd83916da2e4cae03d350015c82a67b1b334c4 ] The Google Coreboot implementation requires IOMEM functions (memmremap, memunmap, devm_memremap), but does not specify this is its Kconfig. This results in build errors when HAS_IOMEM is not set, such as on some UML configurations: /usr/bin/ld: drivers/firmware/google/coreboot_table.o: in function `coreboot_table_probe': coreboot_table.c:(.text+0x311): undefined reference to `memremap' /usr/bin/ld: coreboot_table.c:(.text+0x34e): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/memconsole-coreboot.o: in function `memconsole_probe': memconsole-coreboot.c:(.text+0x12d): undefined reference to `memremap' /usr/bin/ld: memconsole-coreboot.c:(.text+0x17e): undefined reference to `devm_memremap' /usr/bin/ld: memconsole-coreboot.c:(.text+0x191): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_destroy.isra.0': vpd.c:(.text+0x300): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_init': vpd.c:(.text+0x382): undefined reference to `memremap' /usr/bin/ld: vpd.c:(.text+0x459): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_probe': vpd.c:(.text+0x59d): undefined reference to `memremap' /usr/bin/ld: vpd.c:(.text+0x5d3): undefined reference to `memunmap' collect2: error: ld returned 1 exit status Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core") Acked-By: anton ivanov <anton.ivanov@cambridgegreys.com> Acked-By: Julius Werner <jwerner@chromium.org> Signed-off-by: David Gow <davidgow@google.com> Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 37fd83916da2e4cae03d350015c82a67b1b334c4 ]

The Google Coreboot implementation requires IOMEM functions
(memmremap, memunmap, devm_memremap), but does not specify this is its
Kconfig. This results in build errors when HAS_IOMEM is not set, such as
on some UML configurations:

/usr/bin/ld: drivers/firmware/google/coreboot_table.o: in function `coreboot_table_probe':
coreboot_table.c:(.text+0x311): undefined reference to `memremap'
/usr/bin/ld: coreboot_table.c:(.text+0x34e): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/memconsole-coreboot.o: in function `memconsole_probe':
memconsole-coreboot.c:(.text+0x12d): undefined reference to `memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x17e): undefined reference to `devm_memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x191): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_destroy.isra.0':
vpd.c:(.text+0x300): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_init':
vpd.c:(.text+0x382): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x459): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_probe':
vpd.c:(.text+0x59d): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x5d3): undefined reference to `memunmap'
collect2: error: ld returned 1 exit status

Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core")
Acked-By: anton ivanov <anton.ivanov@cambridgegreys.com>
Acked-By: Julius Werner <jwerner@chromium.org>
Signed-off-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>