CyberSecBulletin
CVE-2024-47742NVD status: Modified

Linux: Improper Limitation of a Pathname to a Restricted Directory

Published Updated By the CyberSecBulletin desk

CVE-2024-47742 is a high-severity improper limitation of a pathname to a restricted directory vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions d1768e5535d3ded59f888637016e6f821f4e069f, 9b1ca33ebd05b3acef5b976c04e5e791af93ce1b, c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.29% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to d1768e5535d3ded59f888637016e6f821f4e069f or 9b1ca33ebd05b3acef5b976c04e5e791af93ce1b or c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 or a77fc4acfd49fc6076e565445b2bc5fdc3244da4, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 4.19.323 or 5.4.285 or 5.10.227 or 5.15.168, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinuxabb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, d1768e5535d3ded59f888637016e6f821f4e069f; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, 9b1ca33ebd05b3acef5b976c04e5e791af93ce1b; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, c30558e6c5c9ad6c86459d9acce1520ceeab9ea6; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, a77fc4acfd49fc6076e565445b2bc5fdc3244da4; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, 3d2411f4edcb649eaf232160db459bb4770b5251; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, 7420c1bf7fc784e587b87329cc6dfa3dca537aa4; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, 28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb; abb139e75c2cdbb955e840d6331cb5863e409d0e up to, but not including, 6c4e13fdfcab34811c3143a0a03c05fec4e870ec; and 2 more rangesd1768e5535d3ded59f888637016e6f821f4e069f, 9b1ca33ebd05b3acef5b976c04e5e791af93ce1b, c30558e6c5c9ad6c86459d9acce1520ceeab9ea6, a77fc4acfd49fc6076e565445b2bc5fdc3244da4, 3d2411f4edcb649eaf232160db459bb4770b5251, 7420c1bf7fc784e587b87329cc6dfa3dca537aa4
DebianDebian Linux11.0Not stated
LinuxLinux Kernel3.7 up to, but not including, 4.19.323; 4.20 up to, but not including, 5.4.285; 5.5 up to, but not including, 5.10.227; 5.11 up to, but not including, 5.15.168; 5.16 up to, but not including, 6.1.113; 6.2 up to, but not including, 6.6.54; 6.7 up to, but not including, 6.10.13; 6.11 up to, but not including, 6.11.24.19.323, 5.4.285, 5.10.227, 5.15.168, 6.1.113, 6.6.54

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
LocalThe attacker needs local access or must trick a user into running something.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.

Scoring systemScoreSeverityScored by
CVSS 3.17.8HighCNA
CVSS 3.17.8HighNVD

Official 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Limitation of a Pathname to a Restricted Directory

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

How developers prevent this class of flaw

  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

More Improper Limitation of a Pathname to a Restricted Directory vulnerabilities (CWE-22)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Third-party and government advisories

Recent Improper Limitation of a Pathname to a Restricted Directory vulnerabilities

Spotted an error? Tell us.