CVE-2021-47318 Affecting kernel-zfcpdump-modules-internal package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating

    Threat Intelligence

    EPSS
    0.04% (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 ID SNYK-RHEL9-KERNELZFCPDUMPMODULESINTERNAL-7231982
  • published 10 Jun 2024
  • disclosed 21 May 2024

Introduced: 21 May 2024

New CVE-2021-47318 Open this link in a new tab

How to fix?

There is no fixed version for RHEL:9 kernel-zfcpdump-modules-internal.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-modules-internal package and not the kernel-zfcpdump-modules-internal package as distributed by RHEL. See How to fix? for RHEL:9 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

arch_topology: Avoid use-after-free for scale_freq_data

Currently topology_scale_freq_tick() (which gets called from scheduler_tick()) may end up using a pointer to "struct scale_freq_data", which was previously cleared by topology_clear_scale_freq_source(), as there is no protection in place here. The users of topology_clear_scale_freq_source() though needs a guarantee that the previously cleared scale_freq_data isn't used anymore, so they can free the related resources.

Since topology_scale_freq_tick() is called from scheduler tick, we don't want to add locking in there. Use the RCU update mechanism instead (which is already used by the scheduler's utilization update path) to guarantee race free updates here.

synchronize_rcu() makes sure that all RCU critical sections that started before it is called, will finish before it returns. And so the callers of topology_clear_scale_freq_source() don't need to worry about their callback getting called anymore.

CVSS Scores

version 3.1
Expand this section

Red Hat

5.5 medium