CVE-2023-54013

None

CVSS

—

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake inside the operating system kernel could make the computer freeze when certain power-management and memory operations happen at the same time.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: High
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

The interconnect framework's icc_bw_set() path could deadlock against shrinker/reclaim because icc_lock was held while code paths performed memory allocations during runtime PM resume and similar callbacks.

Why it matters to the business

Kernel deadlocks can cause system hangs or crashes on affected Linux distributions, leading to downtime and potential data loss; urgency is moderate given low exploitability and absence from known campaigns.

How an attack unfolds

An attacker would need to trigger concurrent runtime PM resume operations and memory pressure that invokes reclaim while holding related locks, but the described lockdep cycle has no known public exploit and requires local code execution with specific hardware drivers.

How to fix it

Upgrade the Linux kernel to a version containing commit 2f3a124696d43de3c837f87a9f767c56ee86cf2a or later; for speedtest-go packages apply version 1.7.10-r4 or newer from Chainguard or Wolfi repositories.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source or package changelog; re-run lockdep-enabled kernels under the previously reported call paths and verify absence of the circular dependency warning.

Typical attack path

Obtain local execution context on an affected kernel
Trigger runtime PM resume for a device using interconnect bandwidth changes
Simultaneously induce memory reclaim via allocation pressure
Observe or cause deadlock in icc_lock versus dma_fence_map or fs_reclaim

How to detect it

Examine kernel logs for the lockdep splat mentioning icc_lock, gmu->lock, dma_fence_map, and fs_reclaim; search dmesg or journalctl for icc_bw_set or a6xx_pm_resume call traces around system hangs.

What your security team should do

Prioritize kernel updates on systems using interconnect drivers and runtime PM
Monitor vendor advisories for distribution-specific backports
Test patched kernels in environments exercising PM and memory pressure
Review any custom interconnect or GPU driver code for similar locking patterns

The record

In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix locking for runpm vs reclaim For cases where icc_bw_set() can be called in callbaths that could deadlock against shrinker/reclaim, such as runpm resume, we need to decouple the icc locking. Introduce a new icc_bw_lock for cases where we need to serialize bw aggregation and update to decouple that from paths that require memory allocation such as node/link creation/ destruction. Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_ ---truncated---

Affected packages

Ecosystem	Package	Introduced	Fixed
Linux	Kernel	0	6.5.5
Linux	Kernel	5.1.0	6.5.5