LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysislow

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.
Prepared
Confidence
medium
Sources
7

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
2ADP providers
6Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CVECVE Program Container
CISA-ADPCISA ADP Vulnrichment
other:ssvc
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux386570d76f2f25a347a7118fa54315d56b46e7be, 386570d76f2f25a347a7118fa54315d56b46e7be, 386570d76f2f25a347a7118fa54315d56b46e7be, 386570d76f2f25a347a7118fa54315d56b46e7beunaffected
LinuxLinux4.17, 0, 6.1.132, 6.6.63, 6.9.9, 6.10affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.