CVE-2026-97905: cpufreq: zero-initialize policy cpumask before sysfs publication
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: zero-initialize policy cpumask before sysfs publication
cpufreqpolicyalloc() allocates policy->cpus with alloccpumaskvar(), i.e. without GFPZERO, unlike the sibling relatedcpus and realcpus masks. With CONFIGCPUMASKOFFSTACK=y the mask is a separate kmallocnode() allocation, so its bitmap holds whatever the slab allocator left behind:
cpufreqonline() cpufreqpolicyalloc() alloccpumaskvar(&policy->cpus) / bitmap is uninitialized / kobjectinitandadd() / policy%u/ appears in sysfs / cpufreqpolicyonline() cpumaskcopy(policy->cpus, cpumaskof(cpu)) / first valid value /
This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policyisinactive(), i.e. cpumaskempty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet.
Fix this by using zalloccpumaskvar() for policy->cpus.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Allocate policy->cpus with zalloc_cpumask_var() instead of alloc_cpumask_var() so the cpumask is zero-initialized before sysfs publication.
Linux kernel cpufreq policy->cpus allocation = zalloc_cpumask_var()
Event History
Frequently Asked Questions
Which systems are exposed to the uninitialized cpumask window?
The described condition requires CONFIG_CPUMASK_OFFSTACK=y. In that configuration, policy->cpus is separately allocated without zeroing, so stale slab data can make the mask appear non-empty before cpufreq policy initialization completes.
What access or timing does an attacker need?
An attacker needs to access cpufreq policy sysfs attributes during the interval after the policy directory is published in sysfs and before policy->cpus receives its first valid value. A non-zero residual bitmap causes the inactive-policy check to allow attribute callbacks to run on an incompletely initialized policy.
How can this be mitigated if the fix cannot be applied immediately?
The provided information identifies CONFIG_CPUMASK_OFFSTACK=y as the condition that makes policy->cpus a separate uninitialized allocation. Disabling that configuration avoids the specifically described uninitialized separate bitmap behavior, where feasible.
How can maintainers verify that the issue is fixed in their source tree?
Check whether cpufreq_policy_alloc() allocates policy->cpus with zalloc_cpumask_var() rather than alloc_cpumask_var(). The zero-initializing allocation keeps the mask empty until cpufreq_policy_online() copies in the valid CPU mask.