CVE-2024-42129: leds: mlxreg: Use devm_mutex_init() for mutex initialization
In the Linux kernel, the following vulnerability has been resolved:
leds: mlxreg: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel driver cleanup bug in the mlxreg LED driver. During module removal, the driver could destroy a mutex before an automatic LED unregister path still needs it. The likely business impact is system instability on affected Linux systems using this hardware path, not confirmed remote compromise.
Executive priority
Treat as routine kernel maintenance unless affected Mellanox platform systems are business-critical or showing instability. Prioritize through normal patch windows, with faster action for exposed fleet segments confirmed to use this driver.
Technical view
The vulnerability is in the Linux kernel leds: mlxreg driver. LEDs are registered with devm_led_classdev_register(), but module remove destroyed a mutex before led_classdev_unregister() invoked led_set_brightness() to turn LEDs off. The fix uses devm_mutex_init() so mutex lifetime matches device-managed cleanup.
Likely exposure
Exposure appears limited to Linux systems running affected kernel builds with the mlxreg LED driver present and relevant Mellanox platform hardware or module usage. The provided sources do not show broad default exposure across all Linux servers.
Exploitation context
The source bundle reports no KEV listing, no CVSS, and no cited active exploitation. The described trigger is driver/module cleanup behavior, suggesting local operational fault conditions rather than a known remotely exploitable path.
Researcher notes
Evidence is narrow and kernel-source focused. The core issue is resource lifetime ordering during device-managed LED unregister. The bundle does not provide exploitability analysis, impact beyond cleanup-time misuse of a destroyed mutex, or product-specific exposure outside Linux and Debian LTS references.
Mitigation direction
Update to a vendor kernel containing the referenced stable fixes.
For Debian LTS, review the linked DLA and apply the relevant kernel update.
Reboot into the updated kernel after patching.
If patching is delayed, ask the vendor about safely disabling unused mlxreg LED support.
Validation and detection
Inventory running kernel versions and vendor package advisory status.
Check whether mlxreg LED driver support is built or loaded.
Confirm the deployed kernel includes one of the referenced stable commits.
Review system logs for mlxreg LED or module removal errors.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-42129 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.