CVE-2024-47742

What it actually does

The vulnerability permits path traversal during firmware loading because certain kernel code paths (lpfc, nfp, module_flash_fw) accept device or semi-privileged userspace strings containing ".." without sanitization, allowing resolution of firmware files outside intended directories.

Why it matters to the business

Local attackers with network namespace or device access can load unauthorized firmware, potentially leading to kernel-level compromise, data exfiltration, or persistence on affected Linux systems; urgency is moderate given low EPSS and absence from KEV despite 721 days since publication.

How an attack unfolds

An attacker identifies a vulnerable kernel, crafts a firmware name containing ".." sequences via device descriptors or ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink, and triggers the firmware loader to resolve and load files from arbitrary paths; listed threat actors in 2024 zero-day campaigns and various Linux kernel access vulnerabilities indicate ongoing interest in similar kernel flaws.

How to fix it

Upgrade the Linux kernel to commit d1768e5535d3ded59f888637016e6f821f4e069f or later; for listed packages apply the provided fixed versions (pidgin 2.13.0-5.el8, gdk-pixbuf2 2.36.12-5.el8, gnome-desktop3 3.32.2-1.el8, pango 1.42.4-6.el8).

How to confirm the fix worked

Verify kernel version contains the fix commit; attempt firmware requests containing ".." and confirm rejection in logs or source; confirm no firmware load succeeds for traversed paths.

Typical attack path

1. Gain CAP_NET_ADMIN or equivalent in a network namespace with a mapped ethernet device
2. Construct a firmware filename containing ".." path components
3. Invoke module_flash_fw_schedule or equivalent device firmware update path
4. Cause the firmware loader to resolve and load the traversed file

How to detect it

Inspect kernel logs and dmesg for firmware load attempts; search for request_firmware calls or firmware_class messages that include dot-dot sequences; review audit logs for ETHTOOL netlink commands from untrusted namespaces.

• firmware name containing ".."
• request_firmware.*\.\.
• firmware_class:.*path traversal
• ETHTOOL_MSG_MODULE_FW_FLASH_ACT

What your security team should do

• Prioritize kernel updates on all systems within standard patch windows given low exploit maturity
• Audit custom or third-party drivers that invoke request_firmware with untrusted strings
• Restrict CAP_NET_ADMIN and user-namespace privileges where feasible
• Monitor EPSS trend (stable at 0.0029) and re-evaluate if new exploitation appears