CVE-2024-42129

What it actually does

Use-after-free occurs because devm_led_classdev_register() auto-unregisters LEDs after remove(), calling led_set_brightness() which accesses a mutex already destroyed by the driver's remove() handler instead of using devm_mutex_init().

Why it matters to the business

Affected Linux systems may crash or behave unpredictably when the mlxreg LED driver is unloaded, causing denial of service on servers or devices using these LEDs; high ecosystem prevalence increases urgency for kernel updates.

How an attack unfolds

An attacker with local access triggers driver removal or device unregistration, causing the LED brightness callback to dereference the already-destroyed mutex and potentially escalating to kernel code execution or system instability, consistent with patterns seen in related Linux kernel privilege escalation activity.

How to fix it

Upgrade the Linux kernel to the fixed commit 618c6ce83471ab4f7ac744d27b9d03af173bc141 or any later stable release containing this change; rebuild and deploy updated kernels across all affected systems.

How to confirm the fix worked

Confirm the kernel source contains the devm_mutex_init() call in the mlxreg driver and that the commit 618c6ce83471ab4f7ac744d27b9d03af173bc141 is present; test driver load/unload cycles without triggering mutex errors.

Typical attack path

1. Obtain local access to target Linux system
2. Identify presence of mlxreg LED driver
3. Trigger module removal or device unbind
4. Exploit resulting use-after-free in mutex access

How to detect it

Inspect kernel logs and dmesg for oops traces involving mlxreg LEDs, mutex usage, or led_set_brightness during module unload; correlate with process activity attempting driver removal.

What your security team should do

• Prioritize kernel updates on all production systems within the next patching cycle
• Review and restrict unprivileged module loading where possible
• Monitor kernel logs for related oops or panic messages during driver operations