CVE-2026-80746 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its Display Clock Controller is enabled and references parent clocks from DSI PHYs, which causes clock reparenting issues during probe (init) and warning on Eliza EVK:
disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration. WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273 ... update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P) clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471) clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540) __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368) devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1)) devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104) qcom_cc_really_probe (drivers/clk/qcom/common.c:418) qcom_cc_probe (drivers/clk/qcom/common.c:445) disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza platform_probe (drivers/base/platform.c:1432)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel vulnerability identified in the Qualcomm Display Clock Controller driver for the Eliza Evaluation Kit involves a critical configuration mismatch during hardware initialization. The core issue stems from the fact that while the display subsystem is not enabled on this specific hardware variant, the corresponding clock controller remains active and attempts to configure parent clocks derived from DSI PHYs. This architectural oversight leads to significant operational instability because the driver assumes the presence of functional downstream components that are physically absent or disabled in the Eliza EVK configuration. During the probe phase, which is the initial setup routine executed when a device driver binds to its hardware, the system attempts to reparent clock sources and update their configurations based on incorrect assumptions about available resources.
The technical flaw manifests as a Rate Control Generator stall within the clk_rcg2 module. Specifically, the function update_config fails because it cannot successfully apply the requested clock source changes due to missing or inaccessible parent clocks from the DSI PHYs. This failure triggers a kernel warning indicating that the RCG did not update its configuration properly. The stack trace reveals that this error occurs deep within the common Qualcomm clock controller probing logic, specifically during shared initialization routines for display-related clocks. Such stalls can prevent proper system boot sequences or cause subsequent drivers relying on these clock sources to fail silently or behave unpredictably, as they may receive invalid frequency settings or encounter timeout errors when attempting to enable displays later in the runtime lifecycle.
From a security and stability perspective, this vulnerability primarily impacts system reliability rather than direct data confidentiality or integrity. However, kernel warnings and stalled hardware operations can lead to denial of service conditions where the device fails to initialize correctly, potentially requiring a reboot or manual intervention by administrators. In embedded systems like evaluation kits used for development, such issues hinder debugging efforts and may mask deeper integration problems between clock management frameworks and peripheral drivers. The lack of proper validation checks before attempting clock reparenting allows invalid hardware states to propagate through the kernel's power management infrastructure, increasing the risk of resource leaks or inconsistent state across multiple subsystems that depend on accurate timing signals.
To mitigate this vulnerability, developers must ensure that device tree configurations accurately reflect the physical capabilities and enabled status of all connected peripherals. For platforms like the Eliza EVK where display functionality is intentionally disabled, the corresponding clock controller nodes should either be marked as disabled in the device tree or include specific properties indicating the absence of required parent clocks to prevent initialization attempts. Alternatively, the driver code itself can be enhanced with robust error handling and conditional checks that verify the availability of parent clocks before attempting configuration updates. By implementing these safeguards, the kernel avoids entering invalid states during probe operations, ensuring stable boot processes and preventing unnecessary warning logs that clutter system diagnostics. This aligns with best practices for defensive programming in low-level driver development, emphasizing validation of hardware topology prior to resource allocation or modification.
This issue relates broadly to CWE-20 Improper Input Validation as the kernel fails to adequately validate the presence of expected hardware dependencies before proceeding with configuration tasks. It also touches upon aspects of ATT&CK technique T1496 Resource Hijacking in a broad sense, where system resources are consumed by failed initialization attempts that could otherwise be utilized for legitimate processes. Addressing such vulnerabilities requires close collaboration between hardware architects and software developers to ensure that device tree descriptions match actual board configurations, thereby preventing runtime errors caused by mismatched expectations of available infrastructure.