https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 21 Oct 2026 16:00:46 +0000 https://cve.radiocsirt.org/vuln/cve-2021-47318 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arch_topology: Avoid use-after-free for scale_freq_data</p> <p>Currently topology_scale_freq_tick() (which gets called from scheduler_tick()) may end up using a pointer to &#34;struct scale_freq_data&#34;, 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&#39;t used anymore, so they can free the related resources.</p> <p>Since topology_scale_freq_tick() is called from scheduler tick, we don&#39;t want to add locking in there. Use the RCU update mechanism instead (which is already used by the scheduler&#39;s utilization update path) to guarantee race free updates here.</p> <p>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&#39;t need to worry about their callback getting called anymore.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arch_topology: Avoid use-after-free for scale_freq_data</p> <p>Currently topology_scale_freq_tick() (which gets called from scheduler_tick()) may end up using a pointer to &#34;struct scale_freq_data&#34;, 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&#39;t used anymore, so they can free the related resources.</p> <p>Since topology_scale_freq_tick() is called from scheduler tick, we don&#39;t want to add locking in there. Use the RCU update mechanism instead (which is already used by the scheduler&#39;s utilization update path) to guarantee race free updates here.</p> <p>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&#39;t need to worry about their callback getting called anymore.</p> https://cve.radiocsirt.org/vuln/cve-2021-47318