CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56658 – net: defer final 'struct net' free in netns dismantle
https://notcve.org/view.php?id=CVE-2024-56658
In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? • https://git.kernel.org/stable/c/a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 https://git.kernel.org/stable/c/3e29fa5b742479f73400468314a1c6b9cf553ee4 https://git.kernel.org/stable/c/ce43f6a650a6689551a217276fb0dcca33790425 https://git.kernel.org/stable/c/eeca98948d8c4922e6deb16bfc9ee0bd9902dbb0 https://git.kernel.org/stable/c/1bd631fc9a4515878c1bb7effd19335d2f2d87c2 https://git.kernel.org/stable/c/3267b254dc0a04dfa362a2be24573cfa6d2d78f5 https://git.kernel.org/stable/c/b7a79e51297f7b82adb687086f5cb2da446f1e40 https://git.kernel.org/stable/c/6610c7f8a8d47fd1123eed55ba8c11c24 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56657 – ALSA: control: Avoid WARN() for symlink errors
https://notcve.org/view.php?id=CVE-2024-56657
In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too. • https://git.kernel.org/stable/c/a135dfb5de1501327895729b4f513370d2555b4d https://git.kernel.org/stable/c/d5a1ca7b59804d6779644001a878ed925a4688ca https://git.kernel.org/stable/c/36c0764474b637bbee498806485bed524cad486b https://git.kernel.org/stable/c/b2e538a9827dd04ab5273bf4be8eb2edb84357b0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56655 – netfilter: nf_tables: do not defer rule destruction via call_rcu
https://notcve.org/view.php?id=CVE-2024-56655
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex. Also add a few lockdep asserts to make this more explicit. Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get: WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 In case the synchronize_rcu becomes an issue, we can explore alternatives. One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though. • https://git.kernel.org/stable/c/bfd05c68e4c6320304e9f371ffa356b6e4b9cc53 https://git.kernel.org/stable/c/c03d278fdf35e73dd0ec543b9b556876b9d9a8dc https://git.kernel.org/stable/c/cb401e5799e0acacb405f2128097e9c4ccf82f8a https://git.kernel.org/stable/c/27f0574253f6c24c8ee4e3f0a685b75ed3a256ed https://git.kernel.org/stable/c/7cf0bd232b565d9852cb25fd094f77254773e048 https://git.kernel.org/stable/c/b04df3da1b5c6f6dc7cdccc37941740c078c4043 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56654 – Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating
https://notcve.org/view.php?id=CVE-2024-56654
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is not safe since for the most part entries fetched this way shall be treated as rcu_dereference: Note that the value returned by rcu_dereference() is valid only within the enclosing RCU read-side critical section [1]_. For example, the following is **not** legal:: rcu_read_lock(); p = rcu_dereference(head.next); rcu_read_unlock(); x = p->address; /* BUG!!! */ rcu_read_lock(); y = p->data; /* BUG!!! */ rcu_read_unlock(); • https://git.kernel.org/stable/c/a0bfde167b506423111ddb8cd71930497a40fc54 https://git.kernel.org/stable/c/b475c1109251e30ec21fb574d72a1c71a4ab0039 https://git.kernel.org/stable/c/2ccde10127447c1a5caad8469fede945bdb62fdf https://git.kernel.org/stable/c/0108132d7d76d884e443d18b4f067cdf2811911b https://git.kernel.org/stable/c/f9ecc90b5d501b3a5a62d0685d5104f934bb0104 https://git.kernel.org/stable/c/581dd2dc168fe0ed2a7a5534a724f0d3751c93ae •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56653 – Bluetooth: btmtk: avoid UAF in btmtk_process_coredump
https://notcve.org/view.php?id=CVE-2024-56653
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtk: avoid UAF in btmtk_process_coredump hci_devcd_append may lead to the release of the skb, so it cannot be accessed once it is called. ================================================================== BUG: KASAN: slab-use-after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk] Read of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82 CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c Hardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024 Workqueue: events btusb_rx_work [btusb] Call Trace: <TASK> dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0 btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 82: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60 kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb] btusb_rx_work+0x9e/0xe0 [btusb] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 Freed by task 1733: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0 hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 The buggy address belongs to the object at ffff888033cfab40 which belongs to the cache skbuff_head_cache of size 232 The buggy address is located 112 bytes inside of freed 232-byte region [ffff888033cfab40, ffff888033cfac28) The buggy address belongs to the physical page: page:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa head:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x4000000000000840(slab|head|zone=1) page_type: 0xffffffff() raw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Check if we need to call hci_devcd_complete before calling hci_devcd_append. That requires that we check data->cd_info.cnt >= MTK_COREDUMP_NUM instead of data->cd_info.cnt > MTK_COREDUMP_NUM, as we increment data->cd_info.cnt only once the call to hci_devcd_append succeeds. • https://git.kernel.org/stable/c/0b70151328781a89c89e4cf3fae21fc0e98d869e https://git.kernel.org/stable/c/ecdcaea0e4057171ea4c3783e1cc1c900ad99125 https://git.kernel.org/stable/c/d20ff1d3cb40479789368f502eedb0a00e4161fc https://git.kernel.org/stable/c/b548f5e9456c568155499d9ebac675c0d7a296e8 •