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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42106 – inet_diag: Initialize pad field in struct inet_diag_req_v2
https://notcve.org/view.php?id=CVE-2024-42106
In the Linux kernel, the following vulnerability has been resolved: inet_diag: Initialize pad field in struct inet_diag_req_v2 KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 • https://git.kernel.org/stable/c/432490f9d455fb842d70219f22d9d2c812371676 https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9 https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2 https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4 https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d •