Cloudanix VulnDB

CVE-2026-90295

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's power-management code for certain chips can corrupt memory if the driver is loaded more than once, which may crash the machine or let an attacker gain higher privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write occurs in imx6q_cpufreq_probe because imx6_soc_volt is freshly allocated per probe while the static soc_opp_count is never reset, so a second probe indexes past the end of the new array and writes one u32 beyond the allocation.

Why it matters to the business

Repeated driver bind/unbind operations on systems using the imx6q cpufreq driver can corrupt kernel memory, leading to crashes, instability, or potential local privilege escalation with no external network access required.

How an attack unfolds

An attacker with local access uses sysfs or platform device interfaces to unbind then rebind the imx6q cpufreq driver; the second probe reuses the stale static soc_opp_count value and performs the out-of-bounds write during array population.

How to fix it

Apply the upstream fix that converts soc_opp_count from static to a local variable inside imx6q_cpufreq_probe; rebuild and deploy the updated kernel; reboot or reload the cpufreq driver after installation.

How to confirm the fix worked

Confirm the source change in drivers/cpufreq/cpufreq-imx6q.c, rebuild with KASAN enabled, and verify that multiple unbind/rebind cycles no longer produce slab-out-of-bounds reports during imx6q_cpufreq_probe.

Typical attack path

  1. Locate a system exposing the imx6q cpufreq platform device
  2. Write to the driver's unbind sysfs attribute to detach it
  3. Write to the bind sysfs attribute to reattach it
  4. Trigger the probe path that performs the out-of-bounds write

How to detect it

Search kernel logs and dmesg for KASAN slab-out-of-bounds reports originating from imx6q_cpufreq_probe immediately after bind_store or platform_probe activity; correlate with sysfs writes to driver bind attributes.

  • BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe
  • imx6q_cpufreq_probe+0x3b0/0xa34
  • Write of size 4 at addr
  • bind_store from kernfs_fop_write_iter

What your security team should do

  • Patch kernels containing the imx6q cpufreq driver at the earliest maintenance window
  • Restrict unprivileged write access to cpufreq and platform device sysfs bind/unbind files
  • Add kernel log monitoring for KASAN reports mentioning imx6q_cpufreq_probe

The record

In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.

Affected packages

Ecosystem Package Introduced Fixed