Answer in brief
CVE-2026-97905 records a Unknown severity vulnerability in cpufreq: zero-initialize policy cpumask before sysfs publication. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2fc3384dc75bf7333384c7a16d12c796f61c3f56 <0de2f3918fbbbb767e7e716178194b66560dd12a || >=2fc3384dc75bf7333384c7a16d12c796f61c3f56 <6e166b9281dec98aed19213a84235250e5fdb081 || >=2fc3384dc75bf7333384c7a16d12c796f61c3f56 <bbc0472d2270bf732142ca71579d6ede636174ed || >=2fc3384dc75bf7333384c7a16d12c796f61c3f56 <54d37bcf2f497140b9207968557ddb484058e749 | 0de2f3918fbbbb767e7e716178194b66560dd12a, 6e166b9281dec98aed19213a84235250e5fdb081, bbc0472d2270bf732142ca71579d6ede636174ed, 54d37bcf2f497140b9207968557ddb484058e749 |
| Linux/Linuxgeneric | 4.2 | Not reported |
Published upstream
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
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.
Quoted source text, attributed separately from HOL analysis.