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: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYINGhrtimers are migrated away from the dying CPU to any online target atthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timershandling tasks involved in the CPU hotplug forward progress.However wakeups can still be performed by the outgoing CPU afterCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers beingarmed. Depending on several considerations (crystal ball power managementbased election, earliest timer already enqueued, timer migration enabled ornot), the target may eventually be the current CPU even if offline. If thathappens, the timer is eventually ignored.The most notable example is RCU which had to deal with each and every ofthose wake-ups by deferring them to an online CPU, along with relatedworkarounds:_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)The problem isn't confined to RCU though as the stop machine kthread(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the endof its work through cpu_stop_signal_done() and performs a wake up thateventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace:
No PoCs from references.
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/w4zu/Debian_security