CVE Catalog

CVE-2026-97905

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, in cpufreq, the policy CPU mask (policy->cpus) is allocated without zeroing (alloc_cpumask_var), leaving the bitmap uninitialized. Sysfs attributes are published before the mask is initialized, allowing access to invalid data.

Risk Assessment

An uninitialized CPU mask may lead to incorrect behavior of sysfs attributes, potentially resulting in configuration errors or security breaches.

Recommendation

Use zalloc_cpumask_var() for policy->cpus to ensure the mask is zeroed before sysfs publication.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(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 policy_is_inactive(), i.e. cpumask_empty(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 zalloc_cpumask_var() for policy->cpus.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS