CVE-2026-64373

What it actually does

This is a Linux kernel race condition in the cpufreq subsystem during reboot. On the reboot path, cpufreq_suspend() can run while userspace and kernel threads are still active because the reboot flow does not freeze processes the way a normal suspend path does. If CPU hotplug activity occurs concurrently, governor-related cpufreq state can be freed while cpufreq_suspend() is still using it, causing a NULL pointer dereference in kernel context. The practical technical result is a kernel crash or failed reboot, most likely a local denial-of-service condition. There is no public indication from the provided data that this enables privilege escalation, code execution, or remote exploitation.

Why it matters to the business

Systems using affected Linux kernel builds may crash, hang, or fail during reboot when CPU hotplug activity overlaps with cpufreq shutdown handling. In production environments, this can cause unplanned downtime, delayed maintenance windows, failed automated patching or reboot workflows, service disruption, and possible need for manual recovery. The risk is currently lower urgency than actively exploited vulnerabilities because EPSS is very low, it is not in the CISA KEV catalog, it is not associated with ransomware use, and exploit maturity is listed as none; however, kernel availability bugs can still materially affect reliability at scale.

How an attack unfolds

An attacker would need local capability to influence CPU hotplug behavior and to cause or coincide with a system reboot. During reboot, the kernel calls device_shutdown(), which invokes cpufreq_suspend(). Because the reboot path does not freeze other execution contexts, CPU hotplug operations can proceed at the same time. If the hotplug path tears down or frees cpufreq governor data while cpufreq_suspend() is still referencing it, the kernel dereferences a NULL or invalid governor_data pointer and crashes. In realistic scenarios, this is most likely exploitable by a privileged local user, compromised administrator-level process, misconfigured management agent, or workload with access to CPU hotplug controls rather than by a remote unauthenticated attacker.

How to fix it

Upgrade to a Linux kernel version that includes the cpufreq fix adding cpus_read_lock()/cpus_read_unlock() around cpufreq_suspend() to serialize it against CPU hotplug. If using a distribution kernel, apply the vendor-provided kernel security or stable update rather than attempting to patch manually. Because exact affected products and fixed versions were not provided, confirm applicability through the relevant Linux distribution, appliance vendor, cloud image, or embedded device vendor advisory. As a temporary mitigation where patching is delayed, restrict CPU hotplug interfaces to trusted administrators, avoid concurrent CPU online/offline automation during reboot workflows, and review orchestration or power-management tooling that manipulates CPU hotplug state.

How to confirm the fix worked

Confirm the running kernel contains the upstream or vendor backport for the cpufreq hotplug-suspend race fix. Validate by checking the installed kernel package changelog or vendor advisory for the cpufreq_suspend CPU hotplug locking fix. On source-based or internally maintained kernels, verify that cpufreq_suspend() takes the CPU hotplug read lock using cpus_read_lock() before accessing cpufreq policy/governor state and releases it with cpus_read_unlock(). Operationally, after patching, perform controlled reboot testing on representative systems while ensuring CPU hotplug automation is disabled or safely serialized, and confirm no cpufreq_suspend NULL pointer dereference appears in kernel logs.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel build.
2. Gain sufficient privileges or access to trigger CPU hotplug operations, typically through sysfs CPU online/offline controls or a management interface that performs CPU hotplug.
3. Trigger or wait for a reboot sequence while CPU hotplug operations are occurring.
4. Race CPU hotplug teardown against cpufreq_suspend() during device shutdown.
5. Cause cpufreq governor data to be freed while still in use by the reboot-time cpufreq suspend path.
6. Induce a kernel NULL pointer dereference, leading to crash, reboot failure, or denial of service.

How to detect it

Detection should focus on evidence of kernel crashes during reboot involving cpufreq_suspend and concurrent CPU hotplug activity. Review persistent system journals, kernel ring buffers, crash dumps, pstore/ramoops records, netconsole output, serial console logs, hypervisor console captures, and out-of-band management event logs. Look for NULL pointer dereferences with call traces containing cpufreq_suspend(), device_shutdown(), kernel_restart(), or architecture-specific reboot syscall handlers such as arm64_sys_reboot(). Also review audit logs or shell histories for writes to CPU hotplug sysfs paths, especially /sys/devices/system/cpu/cpu*/online, shortly before reboot or crash events. Because this race may also occur accidentally through management automation, logs alone may not prove malicious exploitation; correlate suspicious local users, automation accounts, process execution, and timing of CPU online/offline operations with the crash window.

• Unable to handle kernel NULL pointer dereference
• cpufreq_suspend+
• device_shutdown+
• kernel_restart+
• arm64_sys_reboot+
• do_kernel_fault+
• /sys/devices/system/cpu/cpu*/online
• echo 0 > /sys/devices/system/cpu/cpu
• echo 1 > /sys/devices/system/cpu/cpu
• CPU hotplug
• governor_data

What your security team should do

• Prioritize patching Linux systems where reboot reliability is critical, including virtualization hosts, appliances, edge systems, clustered services, and systems using CPU hotplug or aggressive power-management automation.
• Track vendor advisories for the relevant Linux distributions and kernel package streams, because fixed package versions were not provided in the input.
• Restrict write access to CPU hotplug sysfs controls and review any delegated administrative tooling that can online or offline CPUs.
• Temporarily disable or serialize CPU hotplug automation during reboot and maintenance windows until patched.
• Search historical kernel logs for cpufreq_suspend crashes or NULL pointer dereferences during reboot to identify potentially affected systems.
• Include this issue in kernel update validation plans, especially for ARM64 and systems using cpufreq governors, because the provided crash trace is from arm64.
• Treat observed exploitation primarily as a reliability or local denial-of-service event unless additional evidence indicates privilege escalation or arbitrary code execution.