Strix
64.9K

CVE-2026-97905

Unknown

Last modified

CVE-2026-97905 is a vulnerability of currently unknown severity. 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.

Description

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.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 2fc3384dc75bf7333384c7a16d12c796f61c3f56, < 0de2f3918fbbbb767e7e716178194b66560dd12a; >= 2fc3384dc75bf7333384c7a16d12c796f61c3f56, < 6e166b9281dec98aed19213a84235250e5fdb081; >= 2fc3384dc75bf7333384c7a16d12c796f61c3f56, < bbc0472d2270bf732142ca71579d6ede636174ed; >= 2fc3384dc75bf7333384c7a16d12c796f61c3f56, < 54d37bcf2f497140b9207968557ddb484058e749
LinuxLinux4.2

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-97905?
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.
How severe is CVE-2026-97905?
Severity scoring for CVE-2026-97905 is pending analysis.
How do I fix CVE-2026-97905?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-97905?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST