CVE-2026-64373 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: Fix hotplug-suspend race during reboot
During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active.
This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference:
Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200
Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress.
[ rjw: Changelog edits ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability resides within the linux kernel's cpu frequency scaling subsystem where a race condition occurs during system reboot operations. This issue specifically affects the cpufreq subsystem's handling of cpu frequency governor data during the reboot process, creating a potential null pointer dereference that could lead to system instability or crashes.
The technical flaw manifests when the kernel restarts through the kernel_restart() -> device_shutdown() call chain, where cpufreq_suspend() is invoked. Unlike normal suspend operations that properly sequence through freeze_processes(), the reboot path maintains active userspace processes and kernel threads without this crucial synchronization step. This creates an environment where cpu hotplug operations can execute concurrently with cpufreq_suspend(), resulting in a classic race condition scenario.
During normal system operation, cpu hotplug mechanisms and cpufreq subsystem should maintain proper coordination to prevent data access conflicts. However, the reboot path bypasses the standard freeze_processes() mechanism that would normally prevent concurrent cpu hotplug activities while system shutdown operations are underway. The governor_data structure, which contains critical frequency scaling configuration information, becomes vulnerable to premature deallocation by hotplug operations while cpufreq_suspend() attempts to access it.
This race condition directly maps to CWE-362, a classic concurrent execution race condition vulnerability where multiple threads or processes access shared resources without proper synchronization mechanisms. The attack surface is particularly dangerous as it occurs during system reboot operations when the kernel is already under stress from multiple concurrent shutdown activities. The null pointer dereference that results from this condition can cause immediate system crashes and potential data corruption.
The operational impact of this vulnerability extends beyond simple system instability, as it affects critical system recovery procedures and could potentially be exploited to cause denial of service conditions during reboot operations. Attackers could theoretically force system restarts repeatedly to increase the probability of triggering this race condition, leading to persistent availability issues. The specific call trace showing do_kernel_fault() followed by cpufreq_suspend() demonstrates that the kernel cannot properly handle the null pointer access when hotplug operations complete their cleanup while suspend is still in progress.
The fix implements proper synchronization using cpus_read_lock()/cpus_read_unlock() mechanisms around the cpufreq_suspend() function to ensure that cpu hotplug operations are blocked during suspend processing. This approach aligns with established kernel patterns for managing concurrent access to shared resources and prevents the race condition by ensuring exclusive access to cpu frequency governor data during suspension operations. The solution follows ATT&CK technique T1490 for system shutdown/reboot, as it addresses a vulnerability that could be exploited to disrupt normal system operation through carefully timed reboot sequences.
This fix represents a standard approach to resolving race conditions in kernel subsystems where proper locking mechanisms must be implemented to prevent concurrent access patterns that could lead to memory corruption or null pointer dereferences. The implementation ensures that the cpufreq subsystem maintains data integrity during reboot operations while preserving the expected behavior of both cpu hotplug and frequency scaling functionality.
The vulnerability demonstrates the critical importance of proper synchronization in kernel-level code where multiple subsystems must coordinate their activities without creating race conditions. The fix exemplifies the principle that all shared resources accessed during critical system operations must be properly protected against concurrent access, particularly during shutdown and restart sequences where normal process management mechanisms may not be fully active. This type of vulnerability highlights the complexity inherent in kernel development where seemingly simple operations can expose intricate concurrency issues requiring careful consideration of system state transitions and resource management patterns.
The solution's effectiveness relies on proper implementation of read locking mechanisms that prevent cpu hotplug operations from proceeding while cpufreq_suspend() is active, thereby maintaining data consistency throughout the system shutdown process. This approach represents a fundamental best practice in kernel development for managing shared resources during critical system operations and prevents the specific type of memory corruption that could occur when governor_data structures are freed while still being accessed by suspended subsystems.