LiveActive security incident?Get immediate response
CVE Record

CVE-2024-27002: clk: mediatek: Do a runtime PM get on controllers during probe

In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock() Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression. Verified on MT8183 and MT8192 Chromebooks.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

CVE-2024-27002 is a Linux kernel reliability issue in MediaTek clock controller initialization. A lock-order deadlock can occur during device probing, potentially preventing affected hardware from initializing cleanly. The source bundle does not provide CVSS severity or evidence of active exploitation.

Executive priority

Handle through normal kernel patch governance unless affected MediaTek-based devices support critical operations. Escalate if systems show boot hangs, device initialization failures, or unsupported vendor kernels.

Technical view

The issue involves a mutual dependency between mt8183-mfgcfg and generic power domains during probe. One CPU path holds genpd_lock then waits on clk_prepare_lock; another holds clk_prepare_lock then waits on genpd_lock. The kernel fix performs a runtime PM get during MediaTek clock controller probing to avoid clk_register acquiring the genpd lock.

Likely exposure

Exposure appears limited to Linux systems using MediaTek clock controllers, with verification noted on MT8183 and MT8192 Chromebooks. The affected version data references Linux 5.2 through 6.9-era ranges, but exact exposure depends on vendor kernel backports, hardware, and distribution updates.

Exploitation context

No active exploitation is stated in the source bundle, and KEV is false. The described condition is a kernel probe-time deadlock, suggesting availability or boot/device-initialization impact rather than a direct remote compromise path. Evidence for exploitability is incomplete.

Researcher notes

The core signal is lock inversion between genpd and clock framework paths during MediaTek clock controller probing. The public record lacks CVSS, CWE, exploit evidence, and detailed affected product mapping beyond Linux/MediaTek context, so validation should focus on kernel commit presence and hardware relevance.

Mitigation direction

  • Apply vendor or distribution kernel updates that include the referenced stable fixes.
  • Prioritize affected MediaTek-based endpoints and embedded Linux devices.
  • Review Fedora advisories if using Fedora kernel packages.
  • Check Linux stable kernel guidance for your maintained branch.
  • Avoid assuming a generic workaround without vendor confirmation.

Validation and detection

  • Inventory Linux systems using MediaTek SoCs or clock controllers.
  • Compare running kernel builds against vendor fixed package versions.
  • Verify whether referenced stable commits are present in your kernel source.
  • Review boot and kernel logs for MediaTek clock or power-domain probe hangs.
  • Confirm patched systems boot and initialize affected hardware normally.
Prepared
Confidence
medium
Sources
9

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-27002 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
8Source 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
LinuxLinuxacddfc2c261b3653ab1c1b567a427299bac20d31, acddfc2c261b3653ab1c1b567a427299bac20d31, acddfc2c261b3653ab1c1b567a427299bac20d31, acddfc2c261b3653ab1c1b567a427299bac20d31unaffected
LinuxLinux5.2, 0, 6.1.88, 6.6.29, 6.8.8, 6.9affected
Weakness

CWE details

No CWE listed

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