← All Advisories

CVE-2026-97905

Last refreshed2026-10-03

Status: UPDATED  |  Advisory ID: CVE-2026-97905

Key Details

CVECVE-2026-97905
Affected productsLinux Linux

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux
SubsystemsGeneral OT
SectorsMultiple

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-97905
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-97905