CVE-2024-57951

What it actually does

The flaw fails to reset per-CPU hrtimer state (including hres_active and online flags) on certain hotplug round-trips, leaving dangling pointers that can result in use-after-free conditions when timers are later enqueued.

Why it matters to the business

Linux systems performing CPU hotplug may suffer kernel instability, crashes, or local privilege escalation, increasing operational risk on servers and cloud instances that rely on dynamic CPU management.

How an attack unfolds

An attacker with local access repeatedly cycles a CPU through online and partial hot-unplug states to trigger the stale hrtimer CPU base, then triggers timer enqueue operations that dereference invalid pointers, enabling use-after-free exploitation.

How to fix it

Upgrade the Linux kernel to a version containing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be or later; rebuild and reboot with the updated kernel image.

How to confirm the fix worked

Confirm the startup() callback exists in kernel/time/hrtimer.c and that cpu_base.online is correctly set after hotplug; run targeted CPU hotplug stress tests to verify absence of WARN_ON_ONCE in enqueue_hrtimer.

Typical attack path

1. Obtain local user access on the target system
2. Trigger repeated CPU hotplug offline/online transitions
3. Force timer enqueue operations that hit the stale per-CPU state
4. Exploit resulting use-after-free for code execution or denial of service

How to detect it

Search kernel logs for WARN_ON_ONCE messages from enqueue_hrtimer during CPU hotplug events and monitor for use-after-free crashes or slab corruption in hrtimer-related structures.

What your security team should do

• Apply the referenced kernel commit or distribution backport immediately on all affected systems
• Prioritize patching servers that perform frequent CPU hotplug or live migration
• Enable kernel hardening features such as KASAN and lockdep during testing of the fix