Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:hrtimers: Handle CPU state correctly on hotplugConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfwaythrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back toCPUHP_ONLINE:Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains setto 1 throughout. However, during a CPU unplug operation, the tick and theclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the onlinestate, for instance CFS incorrectly assumes that the hrtick is alreadyactive, and the chance of the clockevent device to transition to oneshotmode is also lost forever for the CPU, unless it goes back to a lower statethan CPUHP_HRTIMERS_PREPARE once.This round-trip reveals another issue; cpu_base.online is not set to 1after 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, whichmeans there are dangling pointers in the worst case.Address this by adding a corresponding startup() callback, which resets thestale 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 ]
No PoCs from references.
- https://github.com/w4zu/Debian_security