PT-2026-98569 · Linux · Linux

CVE-2026-97905

·

Published

2026-09-25

·

Updated

2026-09-25

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-97905

Affected Products

Linux