CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-49982 – aoe: fix the potential use-after-free problem in more places
https://notcve.org/view.php?id=CVE-2024-49982
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue. • https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65 https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4 https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62 https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662 https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20a •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49981 – media: venus: fix use after free bug in venus_remove due to race condition
https://notcve.org/view.php?id=CVE-2024-49981
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/5098b9e6377577fe13d03e1d8914930f014a3314 https://git.kernel.org/stable/c/63bbe26471ebdcc3c20bb4cc3950d666279ad658 https://git.kernel.org/stable/c/60b6968341a6dd5353554f3e72db554693a128a5 https://git.kernel.org/stable/c/bf6be32e2d39f6301ff1831e249d32a8744ab28a https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621 https://git.kernel.org/stable/c/b0686aedc5f1343442d044bd64eeac7e7a391f4e https://git.kernel.org/stable/c/d925e9f7fb5a2dbefd1a73fc01061f38c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49980 – vrf: revert "vrf: Remove unnecessary RCU-bh critical section"
https://notcve.org/view.php?id=CVE-2024-49980
In the Linux kernel, the following vulnerability has been resolved: vrf: revert "vrf: Remove unnecessary RCU-bh critical section" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: ================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(rlock-AF_PACKET); <Interrupt> lock(rlock-AF_PACKET); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket_rcv+0x863/0x3b30 dev_queue_xmit_nit+0x709/0xa40 vrf_finish_direct+0x26e/0x340 [vrf] vrf_l3_out+0x5f4/0xe80 [vrf] __ip_local_out+0x51e/0x7a0 [...] • https://git.kernel.org/stable/c/504fc6f4f7f681d2a03aa5f68aad549d90eab853 https://git.kernel.org/stable/c/718a752bd746b3f4dd62516bb437baf73d548415 https://git.kernel.org/stable/c/8c9381b3138246d46536db93ed696832abd70204 https://git.kernel.org/stable/c/e61f8c4d179b2ffc0d3b7f821c3734be738643d0 https://git.kernel.org/stable/c/b04c4d9eb4f25b950b33218e33b04c94e7445e51 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49978 – gso: fix udp gso fraglist segmentation after pull from frag_list
https://notcve.org/view.php?id=CVE-2024-49978
In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/080e6c9a3908de193a48f646c5ce1bfb15676ffc https://git.kernel.org/stable/c/af3122f5fdc0d00581d6e598a668df6bf54c9daa https://git.kernel.org/stable/c/33e28acf42ee863f332a958bfc2f1a284a3659df https://git.kernel.org/stable/c/3cd00d2e3655fad3bda96dc1ebf17b6495f86fea https://git.kernel.org/stable/c/a1e40ac5b5e9077fe1f7ae0eb88034db0f9ae1ab •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-49977 – net: stmmac: Fix zero-division error when disabling tc cbs
https://notcve.org/view.php?id=CVE-2024-49977
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "port_transmit_rate_kbps" to be set to a value of 0, which is then passed to the "div_s64" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error. • https://git.kernel.org/stable/c/b4bca4722fda928810d024350493990de39f1e40 https://git.kernel.org/stable/c/2145583e5995598f50d66f8710c86bb1e910ac46 https://git.kernel.org/stable/c/521d42a1c24d638241220d4b9fa7e7a0ed02b88e https://git.kernel.org/stable/c/a71b686418ee6bcb6d6365f7f6d838d9874d9c64 https://git.kernel.org/stable/c/b8c43360f6e424131fa81d3ba8792ad8ff25a09e https://git.kernel.org/stable/c/f01782804147a8c21f481b3342c83422c041d2c0 https://git.kernel.org/stable/c/e33fe25b1efe4f2e6a5858786dbc82ae4c44ed4c https://git.kernel.org/stable/c/b0da9504a528f05f97d926b4db74ff219 •