CWE-764БазаНеполный
Многократная блокировка критически важного ресурса
Программный продукт блокирует критически важный ресурс большее число раз, чем предполагалось, что приводит к непредвиденному состоянию системы.
Открыть в каталоге с фильтром CWE →Связанные CAPEC
—
Связанные уязвимости
CVE-2024-45029В ядре Linux устранена следующая уязвимость:
i2c: tegra: не помечайте устройства ACPI как безопасные для irq
На машинах ACPI модуль tegra i2c сталкивается с проблемой из-за мьютекса, вызываемого внутри спинлока. Это приводит к следующей ошибке:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
...
Call trace:
__might_sleep
__mutex_lock_common
mutex_lock_nested
acpi_subsys_runtime_resume
rpm_resume
tegra_i2c_xfer
Проблема возникает из-за того, что во время __pm_runtime_resume() спинлок &dev-\>power.lock захватывается до вызова rpm_resume(). Позже rpm_resume() вызывает acpi_subsys_runtime_resume(), который опирается на мьютексы, вызывая ошибку.
Чтобы решить эту проблему, устройства на ACPI теперь помечены как небезопасные для IRQ, учитывая зависимость acpi_subsys_runtime_resume() от мьютексов.
CVE-2024-43834В ядре 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() безопасно.
CVE-2024-44956В ядре Linux устранена следующая уязвимость:
drm/xe/preempt_fence: увеличьте критическую секцию ограждения.
Очень легко вызвать незаметные взаимоблокировки в preempt_fence_work_func(), поскольку мы работаем с одним глобальным упорядоченным wq для сигнализации наших ограждений preempt за кулисами, поэтому, даже если мы сигнализируем конкретное ограждение, все в обратном вызове должно быть в критической секции ограждения, поскольку блокировка в обратном вызове предотвратит сигнализацию других опубликованных ограждений. Если мы увеличим критическую секцию ограждения, чтобы охватить весь обратный вызов, то lockdep должен быть в состоянии понять это лучше и жаловаться, если мы захватим чувствительную блокировку, такую как vm->lock, которая также удерживается при ожидании ограждений preempt.