CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56656 – bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips
https://notcve.org/view.php?id=CVE-2024-56656
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer. • https://git.kernel.org/stable/c/13d2d3d381ee9844f89bd436ab0f44204660027e https://git.kernel.org/stable/c/fe9274027697c69c1430dc7ee568f82b331ef972 https://git.kernel.org/stable/c/24c6843b7393ebc80962b59d7ae71af91bf0dcc1 •
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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56652 – drm/xe/reg_sr: Remove register pool
https://notcve.org/view.php?id=CVE-2024-56652
In the Linux kernel, the following vulnerability has been resolved: drm/xe/reg_sr: Remove register pool That pool implementation doesn't really work: if the krealloc happens to move the memory and return another address, the entries in the xarray become invalid, leading to use-after-free later: BUG: KASAN: slab-use-after-free in xe_reg_sr_apply_mmio+0x570/0x760 [xe] Read of size 4 at addr ffff8881244b2590 by task modprobe/2753 Allocated by task 2753: kasan_save_stack+0x39/0x70 kasan_save_track+0x14/0x40 kasan_save_alloc_info+0x37/0x60 __kasan_kmalloc+0xc3/0xd0 __kmalloc_node_track_caller_noprof+0x200/0x6d0 krealloc_noprof+0x229/0x380 Simplify the code to fix the bug. A better pooling strategy may be added back later if needed. (cherry picked from commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/b0193a31a0ca5a0f9e60bb4a86537d46b98111b8 https://git.kernel.org/stable/c/d7b028656c29b22fcde1c6ee1df5b28fbba987b5 •