CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42113 – net: txgbe: initialize num_q_vectors for MSI/INTx interrupts
https://notcve.org/view.php?id=CVE-2024-42113
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: initialize num_q_vectors for MSI/INTx interrupts When using MSI/INTx interrupts, wx->num_q_vectors is uninitialized. Thus there will be kernel panic in wx_alloc_q_vectors() to allocate queue vectors. • https://git.kernel.org/stable/c/3f703186113fac0f3c965204b2cbb22a03322e2c https://git.kernel.org/stable/c/9edc7a83cd40ac96ff14fe3a17a38f7ace6611df https://git.kernel.org/stable/c/c98969226d1fe0c1dd779db8b1c444bc5294fc83 https://git.kernel.org/stable/c/7c36711a2cd8059c2d24f5e5c1d76e8ea2d5613c •
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 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42107 – ice: Don't process extts if PTP is disabled
https://notcve.org/view.php?id=CVE-2024-42107
In the Linux kernel, the following vulnerability has been resolved: ice: Don't process extts if PTP is disabled The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic. Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs. To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready. • https://git.kernel.org/stable/c/172db5f91d5f7b91670c68a7547798b0b5374158 https://git.kernel.org/stable/c/1c4e524811918600683b1ea87a5e0fc2db64fa9b https://git.kernel.org/stable/c/996422e3230e41468f652d754fefd1bdbcd4604e https://access.redhat.com/security/cve/CVE-2024-42107 https://bugzilla.redhat.com/show_bug.cgi?id=2301766 •