| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-47742: firmware_loader: Block path traversal |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| firmware_loader: Block path traversal |
| |
| 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. |
| |
| The Linux kernel CVE team has assigned CVE-2024-47742 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 4.19.323 with commit d1768e5535d3ded59f888637016e6f821f4e069f |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 5.4.285 with commit 9b1ca33ebd05b3acef5b976c04e5e791af93ce1b |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 5.10.227 with commit c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 5.15.168 with commit a77fc4acfd49fc6076e565445b2bc5fdc3244da4 |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 6.1.113 with commit 3d2411f4edcb649eaf232160db459bb4770b5251 |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 6.6.54 with commit 7420c1bf7fc784e587b87329cc6dfa3dca537aa4 |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 6.10.13 with commit 28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 6.11.2 with commit 6c4e13fdfcab34811c3143a0a03c05fec4e870ec |
| Issue introduced in 3.7 with commit abb139e75c2cdbb955e840d6331cb5863e409d0e and fixed in 6.12 with commit f0e5311aa8022107d63c54e2f03684ec097d1394 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-47742 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/base/firmware_loader/main.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/d1768e5535d3ded59f888637016e6f821f4e069f |
| https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b |
| https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 |
| https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4 |
| https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251 |
| https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4 |
| https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb |
| https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec |
| https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec097d1394 |
