← Back to CVE intelligence
CVE intelligence

CVE-2026-97905

Vulnerability intelligence

Published Sep 25, 2026Sources checked Nov 12, 2026
N/ACVSS not listedScore unavailable
What this means

Review the available evidence

CVE-2026-97905. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Microsoft Security Response Center guidance

Vendor revision: Oct 15, 2026

Release Notes

Vendor-listed releases

  • 6.6.158.1-1
CISA KEVNot listedBased on the latest collected catalog
EPSS0.2%Estimated 30-day exploitation probability
Ransomware useNot markedCISA KEV ransomware field
Threat actors0Source-linked actor relationships
Overview

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.

Source: NVD