CVE-2026-98362 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate
dvfs_get_idx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver.
Treat indexes >= opp count as invalid and return 0, same as idx < 0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The Linux kernel's System Control Processor Interface clock driver contains a critical input validation flaw within the scpi_dvfs_recalc_rate function that allows for out-of-bounds memory access when interacting with firmware-provided data. This vulnerability stems from an incomplete boundary check in the dvfs_get_idx helper routine, which is responsible for mapping voltage-frequency scaling indices to their corresponding operational performance points. The original implementation of this driver failed to enforce a strict upper bound on the index value returned by the system control processor firmware. While negative indexes were correctly rejected as invalid inputs, there was no mechanism to ensure that positive indexes remained within the valid range defined by the number of available operating points in the info->opps array. This oversight creates a scenario where malformed or maliciously crafted responses from the SCP firmware can trigger memory safety violations and incorrect system behavior.
From a technical perspective, this flaw represents an improper input validation issue classified under CWE-129: Improper Validation of Array Index. When the dvfs_get_idx function returns an index that exceeds the allocated size of the operational performance points array but remains positive, subsequent code proceeds to dereference memory locations outside the intended buffer boundaries. This leads directly to a kernel address sanitizer detected out-of-bounds read condition. In practical terms, if the system control processor firmware is buggy or compromised and returns a stale value significantly larger than the expected maximum index, the driver will interpret arbitrary garbage data from adjacent memory regions as valid clock rate information. This not only compromises memory integrity but also introduces severe stability risks by propagating incorrect frequency values to downstream consumers of the clock framework.
The operational impact of this vulnerability extends beyond simple memory corruption errors. By allowing out-of-bounds reads, an attacker with local access who can influence or exploit firmware communication channels could potentially leak sensitive kernel memory contents through side-channel effects or crash the system via a null pointer exception if garbage data leads to invalid pointers later in the execution path. Furthermore, the propagation of incorrect clock rates to consumers such as CPU governors or other hardware drivers can lead to unpredictable system behavior, including performance degradation, thermal issues due to inappropriate frequency scaling, or complete kernel panics that result in denial of service conditions. The lack of upper bound validation dates back to the initial development of the SCPI clock driver, highlighting a long-standing gap in defensive coding practices for firmware interaction layers within the Linux kernel subsystems.
To mitigate this vulnerability and restore secure operation, developers must implement strict upper-bound checking alongside existing lower-bound checks. Specifically, any index returned by dvfs_get_idx that is greater than or equal to the count of available operational performance points should be treated as invalid input. The recommended remediation involves modifying the validation logic in scpi_dvfs_recalc_rate to return zero for both negative indexes and those exceeding the valid range, ensuring consistent handling of out-of-bounds values without attempting to access unauthorized memory regions. This fix aligns with industry best practices for secure firmware interface design as outlined by MITRE ATT&CK techniques related to resource hijacking or system exploitation via local privilege escalation vectors where kernel memory integrity is compromised through improper input validation in driver code.