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 CPUHP_ONLINE to halfway
through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to
CPUHP_ONLINE:

Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set
to 1 throughout. However, during a CPU unplug operation, the tick and the
clockevents are shut down at CPUHP_AP_TICK_DYING. 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 CPUHP_HRTIMERS_PREPARE once.

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

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 ]

https://git.kernel.org/stable/c/14984139f1f2768883332965db566ef26db609e7

https://git.kernel.org/stable/c/15b453db41d36184cf0ccc21e7df624014ab6a1a

https://git.kernel.org/stable/c/2f8dea1692eef2b7ba6a256246ed82c365fdc686

https://git.kernel.org/stable/c/38492f6ee883c7b1d33338bf531a62cff69b4b28

https://git.kernel.org/stable/c/3d41dbf82e10c44e53ea602398ab002baec27e75

https://git.kernel.org/stable/c/95e4f62df23f4df1ce6ef897d44b8e23c260921a

https://git.kernel.org/stable/c/a5cbbea145b400e40540c34816d16d36e0374fbc