CVE-2024-43834

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: fix invalid wait context of page_pool_destroy()<br /> <br /> If the driver uses a page pool, it creates a page pool with<br /> page_pool_create().<br /> The reference count of page pool is 1 as default.<br /> A page pool will be destroyed only when a reference count reaches 0.<br /> page_pool_destroy() is used to destroy page pool, it decreases a<br /> reference count.<br /> When a page pool is destroyed, -&gt;disconnect() is called, which is<br /> mem_allocator_disconnect().<br /> This function internally acquires mutex_lock().<br /> <br /> If the driver uses XDP, it registers a memory model with<br /> xdp_rxq_info_reg_mem_model().<br /> The xdp_rxq_info_reg_mem_model() internally increases a page pool<br /> reference count if a memory model is a page pool.<br /> Now the reference count is 2.<br /> <br /> To destroy a page pool, the driver should call both page_pool_destroy()<br /> and xdp_unreg_mem_model().<br /> The xdp_unreg_mem_model() internally calls page_pool_destroy().<br /> Only page_pool_destroy() decreases a reference count.<br /> <br /> If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we<br /> will face an invalid wait context warning.<br /> Because xdp_unreg_mem_model() calls page_pool_destroy() with<br /> rcu_read_lock().<br /> The page_pool_destroy() internally acquires mutex_lock().<br /> <br /> Splat looks like:<br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.10.0-rc6+ #4 Tainted: G W<br /> -----------------------------<br /> ethtool/1806 is trying to lock:<br /> ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 3 locks held by ethtool/1806:<br /> stack backtrace:<br /> CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7e/0xc0<br /> __lock_acquire+0x1681/0x4de0<br /> ? _printk+0x64/0xe0<br /> ? __pfx_mark_lock.part.0+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> lock_acquire+0x1b3/0x580<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __wake_up_klogd.part.0+0x16/0xc0<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? dump_stack_lvl+0x91/0xc0<br /> __mutex_lock+0x15c/0x1690<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_prb_read_valid+0x10/0x10<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_llist_add_batch+0x10/0x10<br /> ? console_unlock+0x193/0x1b0<br /> ? lockdep_hardirqs_on+0xbe/0x140<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? tick_nohz_tick_stopped+0x16/0x90<br /> ? __irq_work_queue_local+0x1e5/0x330<br /> ? irq_work_queue+0x39/0x50<br /> ? __wake_up_klogd.part.0+0x79/0xc0<br /> ? mem_allocator_disconnect+0x73/0x150<br /> mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_mem_allocator_disconnect+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? rcu_is_watching+0x11/0xb0<br /> page_pool_release+0x36e/0x6d0<br /> page_pool_destroy+0xd7/0x440<br /> xdp_unreg_mem_model+0x1a7/0x2a0<br /> ? __pfx_xdp_unreg_mem_model+0x10/0x10<br /> ? kfree+0x125/0x370<br /> ? bnxt_free_ring.isra.0+0x2eb/0x500<br /> ? bnxt_free_mem+0x5ac/0x2500<br /> xdp_rxq_info_unreg+0x4a/0xd0<br /> bnxt_free_mem+0x1356/0x2500<br /> bnxt_close_nic+0xf0/0x3b0<br /> ? __pfx_bnxt_close_nic+0x10/0x10<br /> ? ethnl_parse_bit+0x2c6/0x6d0<br /> ? __pfx___nla_validate_parse+0x10/0x10<br /> ? __pfx_ethnl_parse_bit+0x10/0x10<br /> bnxt_set_features+0x2a8/0x3e0<br /> __netdev_update_features+0x4dc/0x1370<br /> ? ethnl_parse_bitset+0x4ff/0x750<br /> ? __pfx_ethnl_parse_bitset+0x10/0x10<br /> ? __pfx___netdev_update_features+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? _raw_spin_unlock_irqrestore+0x42/0x70<br /> ? __pm_runtime_resume+0x7d/0x110<br /> ethnl_set_features+0x32d/0xa20<br /> <br /> To fix this problem, it uses rhashtable_lookup_fast() instead of<br /> rhashtable_lookup() with rcu_read_lock().<br /> Using xa without rcu_read_lock() here is safe.<br /> xa is freed by __xdp_mem_allocator_rcu_free() and this is called by<br /> call_rcu() of mem_xa_remove().<br /> The mem_xa_remove() is called by page_pool_destroy() if a reference<br /> count reaches 0.<br /> The xa is already protected by the reference count mechanism well in the<br /> control plane.<br /> So removing rcu_read_lock() for page_pool_destroy() is safe.