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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49976 – tracing/timerlat: Drop interface_lock in stop_kthread()
https://notcve.org/view.php?id=CVE-2024-49976
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the "kthread" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again. • https://git.kernel.org/stable/c/b4fdabffae14cca2c80d99bd81f3f27239ac7f5e https://git.kernel.org/stable/c/4679272d5252720746fd9c5465352cbc5665f230 https://git.kernel.org/stable/c/5bfbcd1ee57b607fd29e4645c7f350dd385dd9ad https://git.kernel.org/stable/c/a4a05ceffe8fad68b45de38fe2311bda619e76e2 https://git.kernel.org/stable/c/09cb44cc3d3df7ade2cebc939d6257a2fa8afc7a https://git.kernel.org/stable/c/db8571a9a098086608c11a15856ff585789e67e8 https://git.kernel.org/stable/c/b484a02c9cedf8703eff8f0756f94618004bd165 •