CVE-2026-90296: cpufreq: imx6q: fix devres accumulation across driver rebind
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: imx6q: fix devres accumulation across driver rebind
imx6socvolt is allocated with devmkcalloc(cpudev, ...), where cpudev is the CPU device from getcpudevice(0). That device is never unbound, so its devres list is never released, and imx6qcpufreqremove() 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: imx6qsettarget() reads it, and nothing may reach that after cpufrequnregisterdriver().
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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the resource leak?
Systems using the Linux kernel's imx6q cpufreq driver are exposed when that driver is probed more than once, such as through driver unbind and rebind. The issue was tested by rebinding the driver on QEMU's mcimx6ul-evk.
What operational condition triggers the problem?
Each probe allocates an array whose lifetime was tied to the CPU device, which is never unbound. As a result, every driver rebind adds an allocation that remains until the system shuts down.
What can be done before applying the fix?
Avoid repeatedly unbinding and rebinding the imx6q cpufreq driver. Restarting the system clears allocations accumulated during prior probes.
How can administrators identify the affected behavior?
The relevant indicator is memory accumulating after repeated imx6q cpufreq driver probe or rebind cycles. The accumulation persists for the lifetime of the system rather than being released when the driver is unbound.