Re: [PATCH v2] firmware_loader: Block path traversal

On Fri, Aug 23, 2024 at 08:38:55PM +0200, Jann Horn wrote:

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 Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem") Signed-off-by: Jann Horn jannh@google.com

---

Changes in v2:

• describe fix in commit message (dakr)
• write check more clearly and with comment in separate helper (dakr)
• document new restriction in comment above request_firmware() (dakr)
• warn when new restriction is triggered
• Link to v1: https://lore.kernel.org/r/20240820-firmware-traversal-v1-1-8699ffaa9276@goog...

---

drivers/base/firmware_loader/main.c | 41 +++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)

diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c index a03ee4b11134..dd47ce9a761f 100644 --- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -849,6 +849,37 @@ static void fw_log_firmware_info(const struct firmware *fw, const char *name, {} #endif +/*

• • Reject firmware file names with ".." path components.
• • There are drivers that construct firmware file names from device-supplied
• • strings, and we don't want some device to be able to tell us "I would like to
• • be sent my firmware from ../../../etc/shadow, please".
• • Search for ".." surrounded by either '/' or start/end of string.
• • This intentionally only looks at the firmware name, not at the firmware base
• • directory or at symlink contents.
• */

+static bool name_contains_dotdot(const char *name) +{

• size_t name_len = strlen(name);
• size_t i;
• if (name_len < 2)

• return false;
  

• for (i = 0; i < name_len - 1; i++) {

• /* do we see a ".." sequence? */
  

• if (name[i] != '.' || name[i+1] != '.')
  

• 	continue;
  

• /* is it a path component? */
  

• if ((i == 0 || name[i-1] == '/') &&
  

•     (i == name_len - 2 || name[i+2] == '/'))
  

• 	return true;
  

• }
• return false;

+}

Why do you open code it, instead of using strstr() and strncmp() like you did in v1? I think your approach from v1 read way better.

/* called from request_firmware() and request_firmware_work_func() */ static int _request_firmware(const struct firmware **firmware_p, const char *name, @@ -869,6 +900,14 @@ _request_firmware(const struct firmware **firmware_p, const char *name, goto out; }

• if (name_contains_dotdot(name)) {

• dev_warn(device,
  

• 	 "Firmware load for '%s' refused, path contains '..' component",
  

• 	 name);
  

• ret = -EINVAL;
  

• goto out;
  

• }
• ret = _request_firmware_prepare(&fw, name, device, buf, size, offset, opt_flags); if (ret <= 0) /* error or already assigned */

@@ -946,6 +985,8 @@ _request_firmware(const struct firmware **firmware_p, const char *name,

•  @name will be used as $FIRMWARE in the uevent environment and
  

•  should be distinctive enough not to be confused with any other
  

•  firmware image for this or any other device.
  

• • It must not contain any ".." path components - "foo/bar..bin" is
• • allowed, but "foo/../bar.bin" is not.
  • Caller must hold the reference count of @device.

---

base-commit: b0da640826ba3b6506b4996a6b23a429235e6923 change-id: 20240820-firmware-traversal-6df8501b0fe4 -- Jann Horn jannh@google.com