CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43846 – lib: objagg: Fix general protection fault
https://notcve.org/view.php?id=CVE-2024-43846
In the Linux kernel, the following vulnerability has been resolved: lib: objagg: Fix general protection fault The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported. Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects. Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1]. Before fixing the root cause, error out when nesting happens and warn. [1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> • https://git.kernel.org/stable/c/9069a3817d82b01b3a55da382c774e3575946130 https://git.kernel.org/stable/c/8161263362154cbebfbf4808097b956a6a8cb98a https://git.kernel.org/stable/c/22ae17a267f4812861f0c644186c3421ff97dbfc https://git.kernel.org/stable/c/565213e005557eb6cc4e42189d26eb300e02f170 https://git.kernel.org/stable/c/5adc61d29bbb461d7f7c2b48dceaa90ecd182eb7 https://git.kernel.org/stable/c/1936fa05a180834c3b52e0439a6bddc07814d3eb https://git.kernel.org/stable/c/499f742fed42e74f1321f4b12ca196a66a2b49fc https://git.kernel.org/stable/c/b4a3a89fffcdf09702b1f161b914e52ab •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43841 – wifi: virt_wifi: avoid reporting connection success with wrong SSID
https://notcve.org/view.php?id=CVE-2024-43841
In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. • https://git.kernel.org/stable/c/c7cdba31ed8b87526db978976392802d3f93110c https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414 https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942 https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3 https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29 https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43839 – bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
https://notcve.org/view.php?id=CVE-2024-43839
In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. • https://git.kernel.org/stable/c/8b230ed8ec96c933047dd0625cf95f739e4939a6 https://git.kernel.org/stable/c/f121740f69eda4da2de9a20a6687a13593e72540 https://git.kernel.org/stable/c/c90b1cd7758fd4839909e838ae195d19f8065d76 https://git.kernel.org/stable/c/6ce46045f9b90d952602e2c0b8886cfadf860bf1 https://git.kernel.org/stable/c/6d20c4044ab4d0e6a99aa35853e66f0aed5589e3 https://git.kernel.org/stable/c/ab748dd10d8742561f2980fea08ffb4f0cacfdef https://git.kernel.org/stable/c/b0ff0cd0847b03c0a0abe20cfa900eabcfcb9e43 https://git.kernel.org/stable/c/e0f48f51d55fb187400e9787192eda09f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43835 – virtio_net: Fix napi_skb_cache_put warning
https://notcve.org/view.php?id=CVE-2024-43835
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix napi_skb_cache_put warning After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case. To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context. • https://git.kernel.org/stable/c/df133f3f96257ee29696c0ed8bd198ec801dc810 https://git.kernel.org/stable/c/19ac6f29bf64304ef04630c8ab56ecd2059d7aa1 https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783 https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620 https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43834 – xdp: fix invalid wait context of page_pool_destroy()
https://notcve.org/view.php?id=CVE-2024-43834
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 ? • https://git.kernel.org/stable/c/c3f812cea0d7006469d1cf33a4a9f0a12bb4b3a3 https://git.kernel.org/stable/c/bf22306d92ca59c59dc4aa3bab14768948193d56 https://git.kernel.org/stable/c/05f646cb2174d1a4e032b60b99097f5c4b522616 https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26 https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482 https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc •