vciy

CVE-2024-27004

INDEX BUILT · 2026-10-18

No source can show you its own past. This one can.

Print this page to keep the view as it stands on this date. Everything hidden behind a disclosure opens, and every receipt prints with its value.

clk: Get runtime PM before walking tree during disable_unused

CVE-2024-270044 of 4 sources documented this
23

rank 23 = 0 + 14 + 0 + 9 + 0

rank@v1 · backlog

Someone is already using it

CISA KEV catalog · public proof-of-concept · FIRST EPSS

EPSS 0.00212  ·  without this subject the record ranks 23

What it costs you if it fires

NVD CVSS base score, then the CNA's own

CVSS 5.5, from NVD  ·  without this subject the record ranks 9

It is getting worse, not staying still

FIRST EPSS series, rescorings and bad loads removed

no persisting rise in 365 days  ·  without this subject the record ranks 23

How much of the world it touches

NVD CPE configurations

14 products in the CPE ranges  ·  without this subject the record ranks 14

Someone else already set the date

CISA KEV remediation due date

no CISA due date  ·  without this subject the record ranks 23

Hindsight · the state

0.00212EPSSNOT IN KEVas of 2026-10-18
Severity5.5 MEDIUMreceipt
Harmpartial impactreceipt
Exploitationnone in held sources
Defensefix version namedreceipt
Movementrisenreceipt
PLATEAU10Minimal movement since 2024-05-01, 836 days at 0.00, as of 2026-08-15. arc-rules@v1

Foresight · where to check next

This record is one instance of CWE-667, improper locking. The index holds 746 prior instances of this class, 2 KEV-listed. taxonomy@v1

Full pattern panel

Color is a claim, not decoration:the hostile worldthe defenseno signal

Running Linux? Check your version

A deterministic range check against the ranges this record publishes. It tells you where a version sits in the record, not whether your deployment is exploitable. No account needed.

Watch this record

Matches your own product list against every record this index holds, and tells you when one of them moves.

What counts as a move

Watch Linux

Set up a watchlist (free with an account: one stack of three products)

Record your call

Keep your verdict, your reason and the evidence together. The record takes its date when you save it.

Patch by…

Or open an investigation: an incident or a near miss on this CVE, kept with its evidence where anyone in your organisation can find it.

Choose your verdict, then sign in or use an email link. Your first 100 records are free. Evidence is frozen when the record is created.

Private to your organization unless you share it. Put the proof link in your ticket so a reviewer can inspect the basis for your call. See how decision records work.

Harm, if it fires from the vector and the weakness

Written for the ticket you're about to file.

Reachneeds local access · low privileges required · no user interaction · low attack complexityreceipt
ImpactComplete availability lossreceipt
Scored fromCVSS v3.1 · NVD's vectorreceipt
Weakness classCWE-667 Improper Lockingreceipt
Published consequencesCWE-667: Availability: DoS: Resource Consumption (CPU)cwe-consequences@4.20

CISA KEV & Federal Remediation Deadline from the record and CISA

The fix, and how long it's been waiting.

Fixed in5.4.275; 5.10.216; 5.15.157; 6.1.88; 6.6.29; 6.8.8; 6.9receipt
Patch available sinceNo dated patch-availability record in held sources. The index holds reference URLs without dates and only the current revision of the CVE record, so the day a fix first existed cannot be derived. Only the versions it landed in.
BOD 26-04 deadlineIf the system is reachable from the internet: 14 days. If not: fix at the next system upgrade.derived
Show full BOD 26-04 deadline

CISA has not scored it, so the directive's own defaults apply: automatable no, technical impact total. Calendar days from the KEV listing or from when you find it on a system, whichever is first. Federal agencies are bound from 7 Dec 2026, and contracts often carry it to suppliers. The directive and its table

Exploit Status & Known PoCs a ladder, not a score

Current rung: Nothing observed in held sources.

  • RUNG 1Nothing observed in held sources
  • RUNG 2Proof-of-concept published
  • RUNG 3Exploited in the wild · CISA KEV listed
  • RUNG 4Ransomware campaign use known

Authority who says so

CVSS, NVD5.5 MEDIUMreceipt
Exploit probability0.00212 · top 89% of all CVEsreceipt
Blast breadth3 products across 3 vendorsderived
Assigned byLinuxreceipt
Recorded changes17 · last 18 Oct 2026derived

Affected & Fixed Versions as published

Affected productLinuxreceipt
Published rangeslinux kernel >= 4.15 < 5.4.275; linux kernel >= 5.5 < 5.10.216; linux kernel >= 5.11 < 5.15.157; linux kernel >= 5.16 < 6.1.88receipt
Show all 14 published ranges
linux kernel >= 4.15 < 5.4.275
linux kernel >= 5.5 < 5.10.216
linux kernel >= 5.11 < 5.15.157
linux kernel >= 5.16 < 6.1.88
linux kernel >= 6.2 < 6.6.29
linux kernel >= 6.7 < 6.8.8
linux kernel 6.9-rc1
linux kernel 6.9-rc2
linux kernel 6.9-rc3
linux kernel 6.9-rc4
debian linux 10.0
fedoraproject fedora 38
fedoraproject fedora 39
fedoraproject fedora 40
Fixed in5.4.275; 5.10.216; 5.15.157; 6.1.88; 6.6.29; 6.8.8; 6.9receipt

A rung lights from a row in the index, never from an assessment. "Held sources" is the true scope of the claim: this index reads the CVE record, NVD, CISA KEV, FIRST's EPSS and public proof-of-concept repositories, and it does not observe attacks.

Unaudited dollar value2 of 3 inputs carry a receipt
Exposure$6,480over the next 30 days, if this record is yours
Movementno material movementthe record holds only daily drift and scoring model releases
Basisassumeda published average, not your estate

$6,480 = $4.99M incident cost x 0.6121449559255632 exposure x 0.00212 likelihood

udv@v1 · unaudited · wrong for you until you say what you run

$4.99M is the cost of a breach that happened, from IBM Cost of a Data Breach Report 2026, global average. It is not the value of any asset of yours. That average already covers breaches of every severity, so scaling it by exposure understates a partial-impact record. That is an assumption, not a measurement. Your own asset value goes in the decision record.

Did this affect your environment?Answering needs an account.

What it is stated by the CNA

In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_ receipt

Read the rest of the CNA's description

subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20 The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread. This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again. Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---

NVD's analysis a second authority

severity
5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
weakness
CWE-667
affected versions
linux kernel >= 4.15 < 5.4.275; linux kernel >= 5.5 < 5.10.216; linux kernel >= 5.11 < 5.15.157; and 11 more, listed in full below

check it yourself git.kernel.org git.kernel.org git.kernel.org git.kernel.org git.kernel.org git.kernel.org +1 morereceipt

Movement the material steps

1 May 20240.00045
17 Mar 20250.00272 · scoring model v2025.03.14
15 Jun 20260.00211 · scoring model v2026.06.15
15 Aug 20260.00212
Show all 17 observations
1 May 20240.00045
3 May 20240.00044
17 Mar 20250.00272
29 Mar 20250.01141
30 Mar 20250.00272
15 Apr 20250.00286
9 Jun 20250.00063
11 Jun 20250.00055
7 Jul 20250.0005
5 Nov 20250.00067
18 Nov 20250.0037
21 Nov 20250.00067
21 Dec 20250.00084
23 Dec 20250.00015
12 May 20260.00017
15 Jun 20260.00211
15 Aug 20260.00212

17 observations held. A highlighted step crossed a promotion threshold. A step marked with a scoring model moved because the instrument was replaced, not because the vulnerability changed. receipt

The full biography

EPSS 0.00212Published2024-05-01Index as of2026-08-15

The record had been public for 2 years, 3 months when this index was last written.

Published 2024-05-01 receipt · Index as of 2026-08-15 derived

The pattern, elsewhere

This record is one instance of CWE-667, improper locking. The index holds 746 prior instances of this class, 2 KEV-listed. cwe-consequences@4.20

CVE-2021-1782 · Apple iOS and iPadOSmatches 5 of 9KEV listed · 2021receipt
CVE-2025-43510 · Apple iOS and iPadOSmatches 4 of 9KEV listed · 2025receipt

746 records in this class held. The six above are ranked by exploit maturity, then recency.

Siblings and hubs

Records related to this one

Browse the index from here

These are index-wide views, not findings about CVE-2024-27004.

What usually comes next

Everything above needs no account. What is below is work: assembling it, scoping it to your estate, watching it, and handing it to someone else.

Everything on this page is free. Public data. Withholding it protects nothing.