CVE-2024-57951

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

hrtimers: Handle CPU state correctly on hotplug

Consider a scenario where a CPU transitions from CPUHPONLINE to halfway through a CPU hotunplug down to CPUHPHRTIMERSPREPARE, and then back to CPUHPONLINE:

Since hrtimerspreparecpu() does not run, cpubase.hresactive remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHPAPTICKDYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHPHRTIMERS_PREPARE once.

This round-trip reveals another issue; cpubase.online is not set to 1 after the transition, which appears as a WARNONONCE in enqueuehrtimer().

Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.

Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.

[ tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback ]