Cyber Resilience

CVE-2024-49985

Linux Kernel 5.0 – 5.10.227

Published
21 October 2024
Modified
03 November 2025
Patch / advisory
CVSS Score v3.1 5.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0020 10th percentile
Risk Priority 41 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2024-49985 is a medium-severity Improper Locking (CWE-667) vulnerability in Linux Linux Kernel. Its CVSS base score is 5.5 (Medium).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 10th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

EU & UK References

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an…

more

AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
T1068 Exploitation for Privilege Escalation Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges.
T1548 Abuse Elevation Control Mechanism Privilege Escalation
Adversaries may circumvent mechanisms designed to control privilege elevation to gain higher-level permissions.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2025-22098Same product: Linux Linux Kernel
CVE-2024-36882Same product: Linux Linux Kernel
CVE-2024-46750Same product: Linux Linux Kernel
CVE-2026-23232Same product: Linux Linux Kernel
CVE-2024-43862Same product: Linux Linux Kernel
CVE-2025-22012Same product: Linux Linux Kernel
CVE-2024-40912Same product: Linux Linux Kernel
CVE-2025-22077Same product: Linux Linux Kernel
CVE-2024-35968Same product: Linux Linux Kernel
CVE-2026-53049Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
6.12 · 5.0 — 5.10.227 · 5.11 — 5.15.168 · 5.16 — 6.1.113

Mitigating Controls

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing can detect race conditions and locking errors before release.

prevents

Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.

prevents

Application security requirements can mandate proper lock acquisition/release patterns.

prevents

Secure architecture principles address thread-safety and resource synchronization.

prevents

Secure coding standards directly prohibit missing or incorrect lock usage.

prevents

Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.

References