CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42112 – net: txgbe: free isb resources at the right time
https://notcve.org/view.php?id=CVE-2024-42112
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: free isb resources at the right time When using MSI/INTx interrupt, the shared interrupts are still being handled in the device remove routine, before free IRQs. So isb memory is still read after it is freed. Thus move wx_free_isb_resources() from txgbe_close() to txgbe_remove(). And fix the improper isb free action in txgbe_open() error handling path. • https://git.kernel.org/stable/c/aefd013624a10f39b0bfaee8432a235128705380 https://git.kernel.org/stable/c/ffe8a87463c8bb885c42ed54540d06ed041e76dc https://git.kernel.org/stable/c/efdc3f54299835ddef23bea651c753c4d467010b https://git.kernel.org/stable/c/935124dd5883b5de68dc5a94f582480a10643dc9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42111 – btrfs: always do the basic checks for btrfs_qgroup_inherit structure
https://notcve.org/view.php?id=CVE-2024-42111
In the Linux kernel, the following vulnerability has been resolved: btrfs: always do the basic checks for btrfs_qgroup_inherit structure [BUG] Syzbot reports the following regression detected by KASAN: BUG: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277 Read of size 8 at addr ffff88814628ca50 by task syz-executor318/5171 CPU: 0 PID: 5171 Comm: syz-executor318 Not tainted 6.10.0-rc2-syzkaller-00010-g2ab795141095 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277 create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922 btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:2382 create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875 btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1340 btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422 btrfs_ioctl+0x99e/0xc60 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcbf1992509 RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509 RDX: 0000000020000280 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcbf19eb660 R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e </TASK> And it also pinned it down to commit b5357cb268c4 ("btrfs: qgroup: do not check qgroup inherit if qgroup is disabled"). [CAUSE] That offending commit skips the whole qgroup inherit check if qgroup is not enabled. But that also skips the very basic checks like num_ref_copies/num_excl_copies and the structure size checks. Meaning if a qgroup enable/disable race is happening at the background, and we pass a btrfs_qgroup_inherit structure when the qgroup is disabled, the check would be completely skipped. Then at the time of transaction commitment, qgroup is re-enabled and btrfs_qgroup_inherit() is going to use the incorrect structure and causing the above KASAN error. [FIX] Make btrfs_qgroup_check_inherit() only skip the source qgroup checks. So that even if invalid btrfs_qgroup_inherit structure is passed in, we can still reject invalid ones no matter if qgroup is enabled or not. Furthermore we do already have an extra safety inside btrfs_qgroup_inherit(), which would just ignore invalid qgroup sources, so even if we only skip the qgroup source check we're still safe. • https://git.kernel.org/stable/c/b5357cb268c41b4e2b7383d2759fc562f5b58c33 https://git.kernel.org/stable/c/c839f73a70f312f477225b64020364e108f08231 https://git.kernel.org/stable/c/ebe5ea02577b2c527958af1b76ac472c7ab53a56 https://git.kernel.org/stable/c/724d8042cef84496ddb4492dc120291f997ae26b •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42110 – net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()
https://notcve.org/view.php?id=CVE-2024-42110
In the Linux kernel, the following vulnerability has been resolved: net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx() The following is emitted when using idxd (DSA) dmanegine as the data mover for ntb_transport that ntb_netdev uses. [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526 [74412.556784] caller is netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5 [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024 [74412.581699] Call Trace: [74412.584514] <TASK> [74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] __netif_rx+0x20/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? irq_thread+0xa8/0x290 [74412.642218] irq_thread+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? • https://git.kernel.org/stable/c/548c237c0a9972df5d1afaca38aa733ee577128d https://git.kernel.org/stable/c/4b3b6c7efee69f077b86ef7f088fb96768e46e1f https://git.kernel.org/stable/c/e3af5b14e7632bf12058533d69055393e2d126c9 https://git.kernel.org/stable/c/858ae09f03677a4ab907a15516893bc2cc79d4c3 https://git.kernel.org/stable/c/e15a5d821e5192a3769d846079bc9aa380139baf https://access.redhat.com/security/cve/CVE-2024-42110 https://bugzilla.redhat.com/show_bug.cgi?id=2301473 • CWE-372: Incomplete Internal State Distinction •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42109 – netfilter: nf_tables: unconditionally flush pending work before notifier
https://notcve.org/view.php?id=CVE-2024-42109
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally flush pending work before notifier syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline] nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Problem is that the notifier does a conditional flush, but its possible that the table-to-be-removed is still referenced by transactions being processed by the worker, so we need to flush unconditionally. We could make the flush_work depend on whether we found a table to delete in nf-next to avoid the flush for most cases. AFAICS this problem is only exposed in nf-next, with commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"), with this commit applied there is an unconditional fetch of table->family which is whats triggering the above splat. • https://git.kernel.org/stable/c/f22954f8c58fd5f5489f5980796914e306757e77 https://git.kernel.org/stable/c/41841b585e53babdfb0fa6fdfa54f6d7c28c1206 https://git.kernel.org/stable/c/2c9f0293280e258606e54ed2b96fa71498432eae https://git.kernel.org/stable/c/4167aa477abcf62b0dfda51f3513280fa73cd588 https://git.kernel.org/stable/c/3325628cb36b7f216c5716e7b5124d9dc81199e4 https://git.kernel.org/stable/c/4c06c13317b9a08decedcd7aaf706691e336277c https://git.kernel.org/stable/c/55a40406aac555defe9bdd0adec9508116ce7cb1 https://git.kernel.org/stable/c/09e650c3a3a7d804430260510534ccbf7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42108 – net: rswitch: Avoid use-after-free in rswitch_poll()
https://notcve.org/view.php?id=CVE-2024-42108
In the Linux kernel, the following vulnerability has been resolved: net: rswitch: Avoid use-after-free in rswitch_poll() The use-after-free is actually in rswitch_tx_free(), which is inlined in rswitch_poll(). Since `skb` and `gq->skbs[gq->dirty]` are in fact the same pointer, the skb is first freed using dev_kfree_skb_any(), then the value in skb->len is used to update the interface statistics. Let's move around the instructions to use skb->len before the skb is freed. This bug is trivial to reproduce using KFENCE. It will trigger a splat every few packets. A simple ARP request or ICMP echo request is enough. • https://git.kernel.org/stable/c/271e015b91535dd87fd0f5df0cc3b906c2eddef9 https://git.kernel.org/stable/c/92cbbe7759193e3418f38d0d73f8fe125312c58b https://git.kernel.org/stable/c/9a0c28efeec6383ef22e97437616b920e7320b67 •