CVE-2026-90296 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: imx6q: fix devres accumulation across driver rebind
imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system.
Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver().
That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release.
Tested by rebinding the driver on qemu's mcimx6ul-evk.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel’s cpufreq subsystem for i.MX6Q processors represents a classic resource management flaw involving improper allocation scope and lifecycle mismatch between allocated memory and its associated device resources. Specifically, the function imx6_soc_volt is allocated using devm_kcalloc against cpu_dev, which is obtained via get_cpu_device(0). This CPU device object persists for the entire lifetime of the system kernel instance because it is a fundamental hardware entity that is never unbound or removed during normal operation. Consequently, any memory allocated through its device resource management (devres) list remains resident in memory indefinitely, as devm_kcalloc ties the allocation to the device’s lifecycle rather than the driver’s operational scope.
This architectural mismatch results in a progressive accumulation of unused memory allocations every time the cpufreq driver is probed or rebound. Since imx6q_cpufreq_remove() does not explicitly free this array and relies on the implicit cleanup provided by devres, the failure to unbind the CPU device means these resources are never reclaimed. This behavior constitutes a resource leak that can lead to memory exhaustion over time, particularly in systems where driver rebinding occurs frequently or under stress conditions. The issue is further compounded by the fact that the file-scope pointer retaining reference to this allocation is not cleared during removal or on failed probe paths, leaving dangling pointers that could potentially be accessed after the underlying devres has been logically marked for release but before actual deallocation in edge cases, although the primary impact here remains the persistent memory leak.
From a technical standards perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective lifetime, and CWE-772, referring to missing release of resource or handle after effective lifetime. The operational flaw stems from an incorrect assumption about device lifecycle management within the kernel’s driver model. By allocating against a permanently bound CPU device instead of the transient platform device associated with the specific driver instance, the developer inadvertently created a long-lived resource tied to a short-lived logical component. This misalignment violates best practices for kernel memory management where allocations should typically be scoped to the entity whose lifecycle matches the allocation's required duration.
The mitigation implemented in this resolution involves reallocating the imx6_soc_volt array against the platform device rather than the CPU device. The platform device is correctly unbound when the driver detaches, ensuring that its associated devres list is released at the appropriate time. This change aligns the memory allocation lifecycle with the actual usage pattern of the data structure, which is accessed by imx6q_set_target() and should cease to be valid after cpufreq_unregister_driver() completes. Additionally, the fix includes clearing the file-scope pointer in both the remove function and on failed probe paths. This prevents potential use-after-free scenarios or stale references that could arise if the driver were to attempt access during cleanup sequences where devres is actively releasing resources.
This type of vulnerability highlights the critical importance of understanding device hierarchy and lifecycle semantics within Linux kernel development. Developers must carefully select the correct parent device for resource allocation to ensure automatic cleanup occurs when intended. The fix has been validated through testing by rebinding the driver on QEMU’s mcimx6ul-evk emulation, confirming that the memory is now correctly released upon unbind. For system administrators and maintainers, this patch resolves a latent stability issue that could degrade performance or cause crashes in long-running systems with frequent driver reloads. It underscores the necessity of rigorous code review focused on resource management patterns to prevent subtle leaks that accumulate silently over time.