The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2024-43834)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2024-43834

medium Nessus Plugin ID 228394

Version 1.2

Version 1.1

Version 1.2 Aug 7, 2025, 10:03 AM CVSS metrics ("CVSSv2 score" set to 6.6) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:N/C:N/I:C/A:C") CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202508071003
Version 1.1 Mar 6, 2025, 7:23 AM New Plugin Feed: 202503060723