CVE-2024-57951

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hrtimers: Handle CPU state correctly on hotplug<br /> <br /> Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway<br /> through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to<br /> CPUHP_ONLINE:<br /> <br /> Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set<br /> to 1 throughout. However, during a CPU unplug operation, the tick and the<br /> clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online<br /> state, for instance CFS incorrectly assumes that the hrtick is already<br /> active, and the chance of the clockevent device to transition to oneshot<br /> mode is also lost forever for the CPU, unless it goes back to a lower state<br /> than CPUHP_HRTIMERS_PREPARE once.<br /> <br /> This round-trip reveals another issue; cpu_base.online is not set to 1<br /> after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().<br /> <br /> Aside of that, the bulk of the per CPU state is not reset either, which<br /> means there are dangling pointers in the worst case.<br /> <br /> Address this by adding a corresponding startup() callback, which resets the<br /> stale per CPU state and sets the online flag.<br /> <br /> [ tglx: Make the new callback unconditionally available, remove the online<br /> modification in the prepare() callback and clear the remaining<br /> state in the starting callback instead of the prepare callback ]