В ядре Linux устранена следующая уязвимость: xdp: исправить недопустимый контекст ожидания page_pool_destroy() Если драйвер использует пул …

В ядре Linux устранена следующая уязвимость: xdp: исправить недопустимый контекст ожидания page_pool_destroy() Если драйвер использует пул страниц, он создает пул страниц с помощью page_pool_create(). Счетчик ссылок пула страниц по умолчанию равен 1. Пул страниц будет уничтожен только тогда, когда счетчик ссылок достигнет 0. page_pool_destroy() используется для уничтожения пула страниц, он уменьшает счетчик ссылок. Когда пул страниц уничтожается, вызывается ->disconnect(), который является mem_allocator_disconnect(). Эта функция внутренне захватывает mutex_lock(). Если драйвер использует XDP, он регистрирует модель памяти с помощью xdp_rxq_info_reg_mem_model(). xdp_rxq_info_reg_mem_model() внутренне увеличивает счетчик ссылок пула страниц, если модель памяти является пулом страниц. Теперь счетчик ссылок равен 2. Чтобы уничтожить пул страниц, драйвер должен вызвать и page_pool_destroy(), и xdp_unreg_mem_model(). xdp_unreg_mem_model() внутренне вызывает page_pool_destroy(). Только page_pool_destroy() уменьшает счетчик ссылок. Если драйвер вызывает page_pool_destroy(), а затем xdp_unreg_mem_model(), мы столкнемся с недопустимым предупреждением о контексте ожидания. Потому что xdp_unreg_mem_model() вызывает page_pool_destroy() с rcu_read_lock(). page_pool_destroy() внутренне захватывает mutex_lock(). Splat выглядит так: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 пытается заблокировать: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 другая информация, которая может помочь нам отладить это: context-{5:5} 3 блокировки, удерживаемые ethtool/1806: трассировка стека: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Имя оборудования: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Вызов трассировки: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? __wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfx___mutex_lock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? __irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfx___nla_validate_parse+0x10/0x10 ? __pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfx___netdev_update_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? __pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20 Чтобы исправить эту проблему, он использует rhashtable_lookup_fast() вместо rhashtable_lookup() с rcu_read_lock(). Использование xa без rcu_read_lock() здесь безопасно. xa освобождается __xdp_mem_allocator_rcu_free(), и это вызывается call_rcu() из mem_xa_remove(). mem_xa_remove() вызывается page_pool_destroy(), если счетчик ссылок достигает 0. xa уже хорошо защищен механизмом счетчика ссылок в плоскости управления. Таким образом, удаление rcu_read_lock() для page_pool_destroy() безопасно.