Cloudanix VulnDB

CVE-2026-90296

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A driver bug can slowly use up memory every time certain hardware controls are reloaded, eventually causing slowdowns or crashes on some devices.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak via devres allocations on a CPU device that is never unbound; repeated driver probes accumulate allocations that persist for the system lifetime.

Why it matters to the business

Gradual memory exhaustion on systems that rebind the cpufreq driver, increasing operational risk and potential downtime on affected embedded or ARM platforms.

How an attack unfolds

An attacker with local access triggers repeated probe and remove cycles of the imx6q cpufreq driver, causing unbounded allocations that eventually deplete available memory.

How to fix it

Apply the upstream kernel fix that allocates against the platform device instead of the CPU device and clears the file-scope pointer on remove and error paths; rebuild and deploy the patched kernel.

How to confirm the fix worked

Rebind the driver multiple times and confirm that the allocated array is released on unbind; verify no file-scope pointer remains after unbind and that memory usage stabilizes.

Typical attack path

  1. Obtain local access or sufficient privileges to interact with the cpufreq driver
  2. Trigger driver unbind and rebind operations repeatedly
  3. Monitor for increasing memory consumption until system instability occurs

How to detect it

Review kernel logs for repeated cpufreq probe/remove events; track system memory counters for unexpected growth correlated with driver activity.

What your security team should do

  • Prioritize patching systems running the vulnerable imx6q cpufreq code
  • Monitor memory usage trends on affected devices
  • Limit local access and driver rebinding privileges where feasible

The record

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.

Affected packages

Ecosystem Package Introduced Fixed