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 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-56651 – can: hi311x: hi3110_can_ist(): fix potential use-after-free
https://notcve.org/view.php?id=CVE-2024-56651
In the Linux kernel, the following vulnerability has been resolved: can: hi311x: hi3110_can_ist(): fix potential use-after-free The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off). The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused. Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting. • https://git.kernel.org/stable/c/a22bd630cfff496b270211745536e50e98eb3a45 https://git.kernel.org/stable/c/303733fdab728d34708014b3096dc69ebae6e531 https://git.kernel.org/stable/c/410054f1cf75378a6f009359e5952a240102a1a2 https://git.kernel.org/stable/c/d20bf7e76136fd4c1e47502a1f5773f2290013ed https://git.kernel.org/stable/c/22e382d47de09e865a9214cc5c9f99256e65deaa https://git.kernel.org/stable/c/dcfcd5fc999b1eb7946de1fd031bc3aaf224c5ae https://git.kernel.org/stable/c/330b0ac34beec4fef8b002549af5bc6d0b6f0836 https://git.kernel.org/stable/c/f3d865a6b791abbc874739ed702ae64ad •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56650 – netfilter: x_tables: fix LED ID check in led_tg_check()
https://notcve.org/view.php?id=CVE-2024-56650
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? • https://git.kernel.org/stable/c/268cb38e1802db560c73167e643f14a3dcb4b07c https://git.kernel.org/stable/c/147a42bb02de8735cb08476be6d0917987d022c2 https://git.kernel.org/stable/c/ad28612ebae1fcc1104bd432e99e99d87f6bfe09 https://git.kernel.org/stable/c/36a9d94dac28beef6b8abba46ba8874320d3e800 https://git.kernel.org/stable/c/ab9916321c95f5280b72b4c5055e269f98627efe https://git.kernel.org/stable/c/a9bcc0b70d9baf3ff005874489a0dc9d023b54c3 https://git.kernel.org/stable/c/c40c96d98e536fc1daaa125c2332b988615e30a4 https://git.kernel.org/stable/c/04317f4eb2aad312ad85c1a17ad81fe75 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56649 – net: enetc: Do not configure preemptible TCs if SIs do not support
https://notcve.org/view.php?id=CVE-2024-56649
In the Linux kernel, the following vulnerability has been resolved: net: enetc: Do not configure preemptible TCs if SIs do not support Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs() to configure preemptible TCs. However, only PF is able to configure preemptible TCs. Because only PF has related registers, while VF does not have these registers. So for VF, its hw->port pointer is NULL. • https://git.kernel.org/stable/c/827145392a4aad635b93e5235b7d7fecc2fa31c7 https://git.kernel.org/stable/c/66127f0d1ecf00604aeab71132bde398fd9ec7c9 https://git.kernel.org/stable/c/b718b68a9964181e24d15138a09ce95785a19002 https://git.kernel.org/stable/c/b2420b8c81ec674552d00c55d46245e5c184b260 •