Use of Uninitialized Resource Affecting kernel-rt-64k-modules-core package, versions *


Severity

Recommended
low

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.2% (9th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-KERNELRT64KMODULESCORE-20288114
  • published30 Sept 2026
  • disclosed25 Sept 2026

Introduced: 25 Sep 2026

NewCVE-2026-97905  (opens in a new tab)
CWE-908  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:10 kernel-rt-64k-modules-core.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-modules-core package and not the kernel-rt-64k-modules-core package as distributed by RHEL. See How to fix? for RHEL:10 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1