CVE-2026-97905: Linux kernel · cpufreq: zero-initialize policy cpumask before sysfs publication
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in e807920031ca32b668f9e7a1efbd21858f03d64b : update Linux kernel when convenient.
Data as of 26 Oct 2026, 12:55 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 11% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in e807920031ca32b668f9e7a1efbd21858f03d64b, e13370c5b549712f49f80234df249303381c53b4, ca52482508b3ac9febe74ca4f732647d394727b8 +5
Exploitation evidence
Disclosed: evidence found.
CVE published 25 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
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.
References
- git.kernel.org/stable/c/e13370c5b549712f49f80234df249303381c53b4 (opens in a new tab)
- git.kernel.org/stable/c/e807920031ca32b668f9e7a1efbd21858f03d64b (opens in a new tab)
- git.kernel.org/stable/c/ca52482508b3ac9febe74ca4f732647d394727b8 (opens in a new tab)
- git.kernel.org/stable/c/06f273d29e5e0fe5c775a65c563fbeed8cd94c7a (opens in a new tab)
- git.kernel.org/stable/c/0de2f3918fbbbb767e7e716178194b66560dd12a (opens in a new tab)
- git.kernel.org/stable/c/6e166b9281dec98aed19213a84235250e5fdb081 (opens in a new tab)
- git.kernel.org/stable/c/bbc0472d2270bf732142ca71579d6ede636174ed (opens in a new tab)
- git.kernel.org/stable/c/54d37bcf2f497140b9207968557ddb484058e749 (opens in a new tab)