CVE-2026-97905

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: zero-initialize policy cpumask before sysfs publication<br /> <br /> cpufreq_policy_alloc() allocates policy-&gt;cpus with alloc_cpumask_var(),<br /> i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus<br /> masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate<br /> kmalloc_node() allocation, so its bitmap holds whatever the slab allocator<br /> left behind:<br /> <br /> cpufreq_online()<br /> cpufreq_policy_alloc()<br /> alloc_cpumask_var(&amp;policy-&gt;cpus) /* bitmap is uninitialized */<br /> kobject_init_and_add() /* policy%u/ appears in sysfs */<br /> cpufreq_policy_online()<br /> cpumask_copy(policy-&gt;cpus, cpumask_of(cpu)) /* first valid value */<br /> <br /> This leaves a window in which the sysfs attributes are already reachable<br /> while policy-&gt;cpus is still garbage. show()/store() gate on<br /> policy_is_inactive(), i.e. cpumask_empty(policy-&gt;cpus), so a non-zero<br /> bitmap makes them run the attribute callbacks on a policy that is not<br /> initialized yet.<br /> <br /> Fix this by using zalloc_cpumask_var() for policy-&gt;cpus.