CVE-2026-64377

What it actually does

This is a Linux kernel memory-management flaw in the Qualcomm hardware CPU frequency driver. The driver allocates per-domain state with device-managed allocation, then incorrectly frees a pointer from that allocation during CPU frequency policy teardown. Because the same memory is still tracked by the kernel's device-resource cleanup mechanism, later device detach or driver cleanup can attempt to free it again. Depending on kernel configuration, hardware platform, allocator behavior, and triggerability, this can result in kernel memory corruption, a kernel crash, or potentially a local privilege-escalation primitive. The issue is specific to systems using the qcom-cpufreq-hw driver, typically Qualcomm-based Linux platforms.

Why it matters to the business

Affected systems may become unstable or crash if the vulnerable driver teardown path is reached, which can disrupt devices, embedded platforms, mobile-derived systems, appliances, or edge infrastructure built on Qualcomm SoCs. Practical exploitation appears low at this time: it is not listed in CISA KEV, is not reported as used in ransomware, has no known public exploit maturity, and has a very low EPSS score. However, kernel memory-corruption issues should still be prioritized for affected Qualcomm-based systems because a reliable exploit could affect system availability and potentially allow an attacker with local access to gain higher privileges.

How an attack unfolds

An attacker would first need access to a system running a vulnerable Linux kernel with the Qualcomm qcom-cpufreq-hw driver active. The attacker would then need to cause the CPU frequency policy exit or related device/driver teardown path to execute, such as through CPU hotplug, driver unbind, platform-device removal, suspend/resume edge cases, or other privileged system-management operations exposed by the platform. When the vulnerable exit handler runs, it calls kfree() on memory that was allocated with devm_kzalloc() and is still owned by device-managed resource cleanup. A later detach or cleanup can free the same allocation again, creating a double-free condition. In many environments this will most likely manifest as a kernel crash or allocator corruption; with additional exploitation work, an attacker may attempt to shape kernel heap state to convert the double free into privilege escalation. No public exploitation or active campaign use is currently known from the provided data.

How to fix it

Apply a Linux kernel update that includes the qcom-cpufreq-hw fix removing the invalid kfree() of devm-managed driver data. Because no affected product list or exact fixed package versions were provided, obtain patched kernels from the relevant Linux distribution, device vendor, BSP provider, Android/embedded platform vendor, or upstream stable kernel branch once available. For systems where immediate patching is not possible, reduce exposure by limiting local shell access, restricting privileged interfaces that can unbind drivers or manipulate CPU hotplug/power-management state, disabling unnecessary debugfs/sysfs access for untrusted users, and avoiding dynamic unload or detach operations for the affected driver where operationally feasible. If the platform does not use Qualcomm qcom-cpufreq-hw, it is unlikely to be exposed to this specific bug.

How to confirm the fix worked

Confirm whether the running kernel contains or loads the qcom-cpufreq-hw driver and whether the kernel source/package includes the fix that removes the kfree(data) call from qcom_cpufreq_hw_cpu_exit(). Validate patch status through distribution package metadata, vendor advisories, kernel changelogs, or source inspection. On source-based or vendor BSP kernels, verify that qcom_cpufreq_hw_cpu_exit() no longer frees policy->driver_data and that cleanup is left to devres. On running systems, check kernel version and package build against the vendor's fixed release, then perform controlled regression testing of CPU frequency scaling, suspend/resume, CPU hotplug if supported, and driver lifecycle behavior. Monitor dmesg during validation for slab allocator warnings, use-after-free reports, double-free messages, kernel oopses, or panics involving qcom_cpufreq_hw.

Typical attack path

1. Identify a Qualcomm-based Linux system running a kernel that includes the vulnerable qcom-cpufreq-hw driver code.
2. Obtain local code execution or access to interfaces capable of influencing CPU hotplug, CPU frequency policy lifecycle, driver unbind, device removal, or platform power-management transitions.
3. Trigger the qcom_cpufreq_hw_cpu_exit() path so the driver incorrectly frees devm-managed per-domain driver data.
4. Cause a later platform-device detach or resource cleanup path to execute, resulting in a second free of the same allocation or an invalid free of an array element.
5. Leverage the resulting kernel allocator corruption to crash the system or, if a reliable exploit is developed, attempt local privilege escalation.

How to detect it

There are no known exploitation campaigns, public exploit indicators, or ransomware use in the provided data, so detection should focus on signs that the vulnerable driver lifecycle was exercised and produced kernel memory corruption. Review kernel logs, persistent crash logs, pstore/ramoops records, serial console output, systemd-journald kernel messages, kdump/vmcore artifacts, and device-management audit logs. Look for kernel warnings or panics that mention double free, invalid free, slab corruption, KASAN/KFENCE reports, qcom_cpufreq_hw_cpu_exit, qcom_cpufreq_hw_cpu_init, qcom-cpufreq-hw, cpufreq policy teardown, CPU hotplug, driver unbind, or platform-device detach. Also review administrative activity preceding crashes for writes to sysfs driver unbind/bind paths, CPU online/offline controls, module unload attempts, debugfs usage, suspend/resume stress testing, or unexpected power-management operations. Because exploitation would likely require local or privileged interaction on many systems, correlate crashes with local login, sudo, container escape attempts, adb/shell access on embedded devices, or management-agent commands.

• qcom-cpufreq-hw
• qcom_cpufreq_hw_cpu_exit
• qcom_cpufreq_hw_cpu_init
• BUG: double free
• double free or corruption
• kernel BUG at mm/slub.c
• KASAN: double-free
• KFENCE: invalid free
• BUG: Bad page state
• slab corruption
• general protection fault
• Unable to handle kernel paging request
• Internal error: Oops
• Kernel panic - not syncing
• /sys/bus/platform/drivers/qcom-cpufreq-hw/unbind
• /sys/bus/platform/drivers/qcom-cpufreq-hw/bind
• /sys/devices/system/cpu/cpu*/online
• policy->driver_data

What your security team should do

• Inventory Linux and embedded systems based on Qualcomm SoCs and determine whether they use the qcom-cpufreq-hw driver.
• Prioritize kernel/vendor BSP updates for affected Qualcomm-based systems even though current EPSS is low and no KEV or ransomware use is reported.
• For externally managed appliances or embedded products, request vendor confirmation that their kernel includes the qcom-cpufreq-hw double-free fix.
• Restrict local administrative access and interfaces that allow driver unbind, CPU hotplug, kernel module operations, power-management testing, or debugfs/sysfs manipulation.
• Enable and review kernel crash, oops, panic, and pstore/ramoops collection on affected device classes to identify instability consistent with kernel memory corruption.
• Where feasible in test environments, use KASAN, KFENCE, or SLUB debugging to validate that patched kernels no longer report double-free behavior in qcom-cpufreq-hw lifecycle paths.
• Track upstream stable kernel and distribution advisories for exact fixed versions if the deployed kernel is downstream, vendor-modified, or part of an embedded BSP.