The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 applicationsThere is no fixed version for RHEL:10 kernel-rt-core.
Note: Versions mentioned in the description apply only to the upstream kernel-rt-core package and not the kernel-rt-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.