kernel/linux.git/drivers/base/firmware_loader/main.c, branch v6.18.21

fs: move name_contains_dotdot() to header

2025-06-16T15:01:22+00:00

Move the helper from the firmware specific code to a header so we can reuse it for coredump sockets. Link: https://lore.kernel.org/20250612-work-coredump-massage-v1-5-315c0c34ba94@kernel.org Signed-off-by: Christian Brauner

firmware_loader: use SHA-256 library API instead of crypto_shash API

2025-04-30T19:55:54+00:00

This user of SHA-256 does not support any other algorithm, so the crypto_shash abstraction provides no value. Just use the SHA-256 library API instead, which is much simpler and easier to use. Also take advantage of printk's built-in hex conversion using %*phN. Signed-off-by: Eric Biggers Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20250428190909.852705-1-ebiggers@kernel.org Signed-off-by: Danilo Krummrich

firmware_loader: Fix possible resource leak in fw_log_firmware_info()

2024-11-13T06:13:50+00:00

The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails. Fixes: 02fe26f25325 ("firmware_loader: Add debug message with checksum for FW file") Signed-off-by: Gaosheng Cui Reviewed-by: Amadeusz Sławiński Reviewed-by: Russ Weight Link: https://lore.kernel.org/r/20241016110335.3677924-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: Reorganize kerneldoc parameter names

2024-10-14T06:21:09+00:00

Reorganize kerneldoc parameter names to match the parameter order in the function header. Problems identified using Coccinelle. Signed-off-by: Julia Lawall Link: https://lore.kernel.org/r/20240930112121.95324-27-Julia.Lawall@inria.fr Signed-off-by: Greg Kroah-Hartman

firmware_loader: Block path traversal

2024-09-03T10:47:55+00:00

Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. Cc: stable@vger.kernel.org Reviewed-by: Danilo Krummrich Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem") Signed-off-by: Jann Horn Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/20240828-firmware-traversal-v3-1-c76529c63b5f@google.com Signed-off-by: Greg Kroah-Hartman

firmware: add nowarn variant of request_firmware_nowait()

2024-06-07T17:44:45+00:00

Device drivers with optional firmware may still want to use the asynchronous firmware loading interface. To avoid printing a warning into the kernel log when the optional firmware is absent, add a nowarn variant of this interface. Signed-off-by: Lucas Stach Reviewed-by: Greg Kroah-Hartman Reviewed-by: Luis Chamberlain Link: https://lore.kernel.org/r/20240516102532.213874-1-l.stach@pengutronix.de Signed-off-by: Vinod Koul

firmware_loader: Suppress warning on FW_OPT_NO_WARN flag

2024-03-07T22:05:09+00:00

Some of the warnings are still being printed even if FW_OPT_NO_WARN is passed for some of the function e.g., firmware_request_nowarn(). Fix it by adding a check for FW_OPT_NO_WARN before printing the warning. Signed-off-by: Mukesh Ojha Reviewed-by: Luis Chamberlain Link: https://lore.kernel.org/r/20240219163954.7719-1-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: Abort all upcoming firmware load request once reboot triggered

2023-10-27T11:30:38+00:00

There could be following scenario where there is a ongoing reboot is going from processA which tries to call all the reboot notifier callback and one of them is firmware reboot call which tries to abort all the ongoing firmware userspace request under fw_lock but there could be another processB which tries to do request firmware, which came just after abort done from ProcessA and ask for userspace to load the firmware and this can stop the ongoing reboot ProcessA to stall for next 60s(default timeout) which may not be expected behaviour everyone like to see, instead we should abort any firmware load request which came once firmware knows about the reboot through notification. ProcessA ProcessB kernel_restart_prepare blocking_notifier_call_chain fw_shutdown_notify kill_pending_fw_fallback_reqs __fw_load_abort fw_state_aborted request_firmware __fw_state_set firmware_fallback_sysfs ... fw_load_from_user_helper .. ... . .. usermodehelper_read_trylock fw_load_sysfs_fallback fw_sysfs_wait_timeout usermodehelper_disable __usermodehelper_disable down_write() Signed-off-by: Mukesh Ojha Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/1698330459-31776-2-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: Refactor kill_pending_fw_fallback_reqs()

2023-10-27T11:30:38+00:00

Rename 'only_kill_custom' and refactor logic related to it to be more meaningful. Signed-off-by: Mukesh Ojha Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/1698330459-31776-1-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: Fix a NULL vs IS_ERR() check

2023-05-31T19:31:00+00:00

The crypto_alloc_shash() function doesn't return NULL, it returns error pointers. Update the check accordingly. Fixes: 02fe26f25325 ("firmware_loader: Add debug message with checksum for FW file") Signed-off-by: Dan Carpenter Reviewed-by: Cezary Rojewski Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/36ef6042-ce74-4e8e-9e2c-5b5c28940610@kili.mountain Signed-off-by: Greg Kroah-Hartman