CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/d925e9f7fb5a2dbefd1a73fc01061f38c7becd4c https://git.kernel.org/stable/c/10941d4f99a5a34999121b314afcd9c0a1c14f15 https://git.kernel.org/stable/c/c5a85ed88e043474161bbfe54002c89c1 •
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49975 – uprobes: fix kernel info leak via "[uprobes]" vma
https://notcve.org/view.php?id=CVE-2024-49975
In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. • https://git.kernel.org/stable/c/d4b3b6384f98f8692ad0209891ccdbc7e78bbefe https://git.kernel.org/stable/c/f561b48d633ac2e7d0d667020fc634a96ade33a0 https://git.kernel.org/stable/c/21cb47db1ec9765f91304763a24565ddc22d2492 https://git.kernel.org/stable/c/24141df5a8615790950deedd926a44ddf1dfd6d8 https://git.kernel.org/stable/c/5b981d8335e18aef7908a068529a3287258ff6d8 https://git.kernel.org/stable/c/2aa45f43709ba2082917bd2973d02687075b6eee https://git.kernel.org/stable/c/9634e8dc964a4adafa7e1535147abd7ec29441a6 https://git.kernel.org/stable/c/34820304cc2cd1804ee1f8f3504ec7781 •