CVE-2021-47318

What it actually does

Use-after-free in topology_scale_freq_tick() called from scheduler_tick() when scale_freq_data pointer is cleared by topology_clear_scale_freq_source() without synchronization, allowing concurrent access to freed memory via RCU-protected paths.

Why it matters to the business

Linux systems may experience kernel crashes, denial of service, or local privilege escalation under specific CPU frequency scaling and topology change workloads, increasing operational risk on servers and embedded devices until patched.

How an attack unfolds

An attacker with local access triggers repeated CPU frequency source registration and unregistration while scheduler ticks occur, racing the freed scale_freq_data pointer to read or write attacker-controlled memory for code execution or crash.

How to fix it

Apply the upstream kernel commit that replaces direct pointer access with RCU update and synchronize_rcu() in topology_clear_scale_freq_source(); rebuild and reboot to the fixed kernel version.

How to confirm the fix worked

Confirm the RCU-protected update pattern and synchronize_rcu() call are present in arch_topology.c; run kernel build tests exercising CPU hotplug and frequency source changes under load; verify no use-after-free reports in KASAN-enabled kernels.

Typical attack path

1. Obtain local user access on a Linux system with dynamic CPU frequency scaling enabled
2. Register and rapidly unregister scale frequency sources to invoke topology_clear_scale_freq_source()
3. Force scheduler_tick() execution to call topology_scale_freq_tick() during the window
4. Leverage freed pointer to corrupt kernel memory or redirect execution

How to detect it

Review kernel logs for oops or panic messages referencing scale_freq_data or topology_scale_freq_tick around CPU frequency or topology change events; inspect for suspicious local processes triggering cpufreq or CPU hotplug operations.

What your security team should do

• Prioritize kernel updates on all multi-core Linux systems with cpufreq enabled
• Monitor for scheduler-related oops or KASAN reports in production workloads
• Restrict unprivileged access to CPU topology or frequency interfaces where feasible
• Test patched kernels in staging environments before broad deployment