В ядре Linux устранена следующая уязвимость: tracing: реструктурировать trace_clock_global(), чтобы никогда не блокироваться. Сообщалось, ч…

В ядре Linux устранена следующая уязвимость: tracing: реструктурировать trace_clock_global(), чтобы никогда не блокироваться. Сообщалось, что исправление обнаружения рекурсии кольцевого буфера приведет к зависанию машины при выполнении тестирования приостановки/возобновления. Следующая трассировка стека была извлечена из отладки этого случая: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 Со следующим RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Поскольку исправление обнаружения рекурсии позволит произойти одной рекурсии во время трассировки, это привело к тому, что trace_clock_global() взял спин-блокировку, а затем попытался взять ее снова: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (что-то еще трассируется трассировщиком графов функций) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Трассировка *никогда* не должна блокироваться, так как это может привести к странным зависаниям, как описано выше. Реструктурируйте код trace_clock_global(), чтобы вместо простого взятия блокировки для обновления записанного "prev_time" просто использовать его, поскольку два события, происходящие на двух разных ЦП, которые вызывают это одновременно, действительно не имеют значения, какое из них произойдет первым. Используйте trylock для захвата блокировки для обновления prev_time, и если это не удастся, просто попробуйте еще раз в следующий раз. Если не удалось ее взять, это означает, что кто-то другой уже обновляет ее. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761