CVE-2024-43834: xdp: fix invalid wait context of page_pool_destroy()
First published: Sat Aug 17 2024(Updated: )
In the Linux kernel, the following vulnerability has been resolved: xdp: fix invalid wait context of page_pool_destroy() If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock(). If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2. To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count. If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock(). Splat looks like: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <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 To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe.
Credit: 416baaa9-dc9f-4396-8d5f-8c081fb06d67 416baaa9-dc9f-4396-8d5f-8c081fb06d67
| Affected Software | Affected Version | How to fix |
|---|---|---|
| Linux Linux kernel | >=5.3.18<5.4 | |
| Linux Linux kernel | >=5.4.5<5.5 | |
| Linux Linux kernel | >=5.5<6.1.103 | |
| Linux Linux kernel | >=6.2<6.6.44 | |
| Linux Linux kernel | >=6.7<6.10.3 | |
| debian/linux | <=5.10.223-1 | 5.10.226-1 6.1.115-1 6.1.112-1 6.11.7-1 6.11.9-1 |
Never miss a vulnerability like this again
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
Reference Links
- https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc2c2a537
- https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26
- https://git.kernel.org/stable/c/59a931c5b732ca5fc2ca727f5a72aeabaafa85ec
- https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a
- https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd
- https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-43834
- https://nvd.nist.gov/vuln/detail/CVE-2024-43834
- https://launchpad.net/bugs/cve/CVE-2024-43834
- https://security-tracker.debian.org/tracker/CVE-2024-43834
- https://ubuntu.com/security/CVE-2024-43834
- https://git.kernel.org/linus/59a931c5b732ca5fc2ca727f5a72aeabaafa85ec
- agent/title
- agent/type
- agent/first-publish-date
- agent/author
- collector/nvd-api
- source/NVD
- agent/software-canonical-lookup
- agent/remedy
- agent/severity
- collector/mitre-cve
- source/MITRE
- agent/last-modified-date
- collector/usn-cve
- source/Ubuntu
- collector/nvd-cve
- agent/references
- collector/security-tracker-debian
- source/Debian
- agent/softwarecombine
- agent/description
- agent/tags
- agent/event
- vendor/linux
- canonical/linux linux kernel
- version/linux linux kernel/5.3.18
- version/linux linux kernel/5.4.5
- version/linux linux kernel/5.5
- version/linux linux kernel/6.2
- version/linux linux kernel/6.7
- package-manager/debian