CVE-2026-80523 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
clk: spacemit: k3: set hdma clock as critical
HDMA clock is responsible for the internal TCM access path of X100 RISC-V core, so set the clock flag as critical to prevent it from being shut off, otherwise the Linux system will hang, for example in the case of a vector instruction access generates a page fault.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The identified vulnerability resides within the Clock Control Unit driver implementation for the Spacemit K3 SoC family, specifically affecting the configuration of the High-Density Memory Access HDMA clock infrastructure. This issue stems from an incorrect default state assignment where the HDMA clock was not designated as a critical resource during system initialization. In complex System-on-Chip architectures like those based on the X100 RISC-V core, various subsystems rely heavily on precise timing and continuous power delivery to maintain data integrity and operational stability. The HDMA controller serves a specialized function by managing high-throughput memory transfers that are integral to the internal Tightly Coupled Memory access path of the processor cores. When this clock signal is allowed to be gated or shut off due to improper reference counting or lack of critical flags, the hardware pathways required for specific low-level operations cease to function correctly.
The technical flaw lies in the absence of a flag indicating that the HDMA clock must remain active at all times during normal system operation. Without this designation, the Linux kernel's generic clock framework may determine that no devices are actively using the clock and subsequently disable it to save power. This behavior is standard for non-critical peripherals but becomes catastrophic when applied to hardware blocks essential for core execution paths. Specifically, when a vector instruction executed by the RISC-V core triggers a page fault or requires access through this internal memory path, the system expects immediate response from the HDMA subsystem. If the clock has been erroneously disabled, the hardware cannot process these requests, leading to an unresponsive state where the processor waits indefinitely for a signal that will never arrive.
The operational impact of this vulnerability is severe and manifests as a complete system hang or kernel panic. The scenario described involves vector instruction access generating a page fault, which requires robust memory management unit interaction mediated by the HDMA infrastructure. When the clock is off, any such event results in a deadlock condition because the hardware cannot service the interrupt or data transfer required to resolve the exception. This leads to a frozen system state where no further software execution can occur until a hard reset is performed. Such instability undermines the reliability of embedded systems relying on this SoC for critical tasks that involve complex vector processing and dynamic memory allocation patterns, potentially causing data loss or service outages in production environments.
From a classification perspective, this issue aligns with CWE-764 Multiple Locks at Critical Endpoint, as it involves improper resource management leading to a deadlock state where the system becomes unresponsive due to missing hardware prerequisites. It also relates to CWE-253 Incorrect Check of Function Return Value in terms of driver initialization logic failing to enforce necessary constraints on clock resources. In the context of MITRE ATT&CK, while this is not an exploit vector for malicious actors per se, it represents a weakness that could be leveraged in denial-of-service scenarios if triggered intentionally through crafted workloads that induce page faults during specific timing windows when power management policies are aggressive.
To mitigate this vulnerability and restore system stability, the primary remediation involves modifying the clock driver source code to explicitly set the HDMA clock as critical. This is achieved by applying the CLK_IS_CRITICAL flag to the clock definition within the Spacemit K3 clock framework initialization routine. By marking the clock as critical, the kernel's power management subsystem will be prevented from gating or disabling it regardless of current usage statistics. Developers must ensure that this change is integrated into the mainline Linux kernel tree for affected SoC variants. Additionally, system integrators should verify their device trees and board-specific configurations to ensure no conflicting overrides exist that might attempt to disable essential clocks during boot sequences. Regular testing involving stress tests with vector instruction sets and memory-intensive workloads can help validate that the clock remains active under all operational conditions, thereby preventing future occurrences of this hang scenario.