CVE-2024-56592 in Linux
Сводка
по VulDB • 28.05.2026
В ядре Linux была устранена следующая уязвимость:
bpf: Вызов free_htab_elem() после htab_unlock_bucket()
Для htab карт (maps), когда карта удаляется из htab, она может удерживать последнюю ссылку на карту. Функция bpf_map_fd_put_ptr() вызывает bpf_map_free_id() для освобождения идентификатора удаляемого элемента карты. Однако bpf_map_fd_put_ptr() вызывается при удержании блокировки корзины (raw_spin_lock_t), а bpf_map_free_id() пытается захватить map_idr_lock (spinlock_t), что вызывает следующее предупреждение lockdep:
============================= [ BUG: Invalid wait context ]
6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 пытается заблокировать: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70
другая информация, которая может помочь в отладке: context-{5:5}
2 блокировки удерживаются test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270
#1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80
трассировка стека: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x59/0x80 dump_stack+0x10/0x18 __lock_acquire+0x1338/0x23c0 lock_acquire+0x119/0x3a0 _raw_spin_lock+0x45/0x60 x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Один из способов исправить предупреждение lockdep — использовать raw_spinlock_t для map_idr_lock. Однако bpf_map_alloc_id() вызывает idr_alloc_cyclic() после захвата map_idr_lock, что вызовет аналогичное предупреждение lockdep, поскольку блокировка slab (s->cpu_slab->lock) все еще является spinlock.
Вместо изменения типа map_idr_lock, проблема исправлена путем вызова htab_put_fd_value() после htab_unlock_bucket(). Однако только откладывание вызова htab_put_fd_value() недостаточно, поскольку старые указатели карт в htab карт не могут быть сохранены во время пакетного удаления. Поэтому также откладывается вызов free_htab_elem(), чтобы эти элементы, подлежащие освобождению, могли быть связаны вместе, аналогично карте lru.
Есть четыре вызывающих для ->map_fd_put_ptr:
(1) alloc_htab_elem() (через htab_put_fd_value()) Она вызывает ->map_fd_put_ptr() под raw_spinlock_t. Вызов htab_put_fd_value() не может быть просто перемещен после htab_unlock_bucket(), поскольку старый элемент уже сохранен в htab->extra_elems. Он может быть немедленно переиспользован после htab_unlock_bucket(), и вызов htab_put_fd_value() после htab_unlock_bucket() может неправильно освободить вновь добавленный элемент. Поэтому сохранение указателя карты старого элемента для htab карт перед разблокировкой корзины и освобождение map_ptr после разблокировки. Кроме указателя карты в старом элементе, следует сделать то же самое для специальных полей в старом элементе.
(2) free_htab_elem() (через htab_put_fd_value()) Ее вызывающие включают __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() и __htab_map_lookup_and_delete_batch().
Для htab_map_delete_elem() просто вызывается free_htab_elem() после htab_unlock_bucket(). Для __htab_map_lookup_and_delete_batch(), как и для lru карты, связывание элементов, подлежащих освобождению, в список node_to_free и вызов free_htab_elem() для этих элементов после разблокировки. Безопасно использовать batch_flink в качестве ссылки для node_to_free, поскольку эти элементы уже удалены из hash llist.
Поскольку htab карт не поддерживает операцию lookup_and_delete, __htab_map_lookup_and_delete_elem() не имеет этой проблемы, поэтому оставлено как
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.