Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: Do not broadcast to other cpus when starting a counter<br /> <br /> This command:<br /> <br /> $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000<br /> <br /> gives rise to this kernel warning:<br /> <br /> [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436<br /> [ 444.364515] Modules linked in:<br /> [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73<br /> [ 444.364771] Hardware name: riscv-virtio,qemu (DT)<br /> [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436<br /> [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32<br /> [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800<br /> [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0<br /> [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0<br /> [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000<br /> [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100<br /> [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000<br /> [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98<br /> [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000<br /> [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001<br /> [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6<br /> [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0<br /> [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 444.365226] [] smp_call_function_many_cond+0x42c/0x436<br /> [ 444.365295] [] on_each_cpu_cond_mask+0x20/0x32<br /> [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa<br /> [ 444.365327] [] riscv_pmu_start+0x48/0x66<br /> [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac<br /> [ 444.365356] [] perf_event_task_tick+0x78/0x8c<br /> [ 444.365368] [] scheduler_tick+0xe6/0x25e<br /> [ 444.365383] [] update_process_times+0x80/0x96<br /> [ 444.365398] [] tick_sched_handle+0x26/0x52<br /> [ 444.365410] [] tick_sched_timer+0x50/0x98<br /> [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a<br /> [ 444.365433] [] hrtimer_interrupt+0xce/0x1da<br /> [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a<br /> [ 444.365457] [] handle_percpu_devid_irq+0x80/0x114<br /> [ 444.365470] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 444.365483] [] riscv_intc_irq+0x2e/0x46<br /> [ 444.365497] [] handle_riscv_irq+0x4a/0x74<br /> [ 444.365521] [] do_irq+0x7c/0x7e<br /> [ 444.365796] ---[ end trace 0000000000000000 ]---<br /> <br /> That&amp;#39;s because the fix in commit 3fec323339a4 ("drivers: perf: Fix panic<br /> in riscv SBI mmap support") was wrong since there is no need to broadcast<br /> to other cpus when starting a counter, that&amp;#39;s only needed in mmap when<br /> the counters could have already been started on other cpus, so simply<br /> remove this broadcast.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()<br /> <br /> The put_device() calls rmi_release_function() which frees "fn" so the<br /> dereference on the next line "fn-&gt;num_of_irqs" is a use after free.<br /> Move the put_device() to the end to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: mux: Add check and kfree for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.<br /> Moreover, use kfree() in the later error handling in order to avoid<br /> memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()<br /> <br /> KMSAN reported the following uninit-value access issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421<br /> virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421<br /> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120<br /> process_one_work kernel/workqueue.c:2630 [inline]<br /> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703<br /> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784<br /> kthread+0x3cc/0x520 kernel/kthread.c:388<br /> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> Uninit was stored to memory at:<br /> virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline]<br /> virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415<br /> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120<br /> process_one_work kernel/workqueue.c:2630 [inline]<br /> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703<br /> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784<br /> kthread+0x3cc/0x520 kernel/kthread.c:388<br /> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523<br /> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559<br /> __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline]<br /> virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58<br /> virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline]<br /> virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387<br /> vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120<br /> process_one_work kernel/workqueue.c:2630 [inline]<br /> process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703<br /> worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784<br /> kthread+0x3cc/0x520 kernel/kthread.c:388<br /> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014<br /> Workqueue: vsock-loopback vsock_loopback_work<br /> =====================================================<br /> <br /> The following simple reproducer can cause the issue described above:<br /> <br /> int main(void)<br /> {<br /> int sock;<br /> struct sockaddr_vm addr = {<br /> .svm_family = AF_VSOCK,<br /> .svm_cid = VMADDR_CID_ANY,<br /> .svm_port = 1234,<br /> };<br /> <br /> sock = socket(AF_VSOCK, SOCK_STREAM, 0);<br /> connect(sock, (struct sockaddr *)&amp;addr, sizeof(addr));<br /> return 0;<br /> }<br /> <br /> This issue occurs because the `buf_alloc` and `fwd_cnt` fields of the<br /> `struct virtio_vsock_hdr` are not initialized when a new skb is allocated<br /> in `virtio_transport_init_hdr()`. This patch resolves the issue by<br /> initializing these fields during allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: verify mac len before reading mac header<br /> <br /> LLC reads the mac header with eth_hdr without verifying that the skb<br /> has an Ethernet header.<br /> <br /> Syzbot was able to enter llc_rcv on a tun device. Tun can insert<br /> packets without mac len and with user configurable skb-&gt;protocol<br /> (passing a tun_pi header when not configuring IFF_NO_PI).<br /> <br /> BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]<br /> BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111<br /> llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]<br /> llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111<br /> llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218<br /> __netif_receive_skb_one_core net/core/dev.c:5523 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637<br /> netif_receive_skb_internal net/core/dev.c:5723 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5782<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555<br /> tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002<br /> <br /> Add a mac_len test before all three eth_hdr(skb) calls under net/llc.<br /> <br /> There are further uses in include/net/llc_pdu.h. All these are<br /> protected by a test skb-&gt;protocol == ETH_P_802_2. Which does not<br /> protect against this tun scenario.<br /> <br /> But the mac_len test added in this patch in llc_fixup_skb will<br /> indirectly protect those too. That is called from llc_rcv before any<br /> other LLC code.<br /> <br /> It is tempting to just add a blanket mac_len check in llc_rcv, but<br /> not sure whether that could break valid LLC paths that do not assume<br /> an Ethernet header. 802.2 LLC may be used on top of non-802.3<br /> protocols in principle. The below referenced commit shows that used<br /> to, on top of Token Ring.<br /> <br /> At least one of the three eth_hdr uses goes back to before the start<br /> of git history. But the one that syzbot exercises is introduced in<br /> this commit. That commit is old enough (2008), that effectively all<br /> stable kernels should receive this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: psi: Add check for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING<br /> <br /> syzbot reported the following uninit-value access issue [1]:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]<br /> BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756<br /> strlen lib/string.c:418 [inline]<br /> strstr+0xb8/0x2f0 lib/string.c:756<br /> tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]<br /> genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066<br /> netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545<br /> genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]<br /> netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368<br /> netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> sock_sendmsg net/socket.c:753 [inline]<br /> ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595<br /> __sys_sendmsg net/socket.c:2624 [inline]<br /> __do_sys_sendmsg net/socket.c:2633 [inline]<br /> __se_sys_sendmsg net/socket.c:2631 [inline]<br /> __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559<br /> __alloc_skb+0x318/0x740 net/core/skbuff.c:650<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]<br /> netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> sock_sendmsg net/socket.c:753 [inline]<br /> ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595<br /> __sys_sendmsg net/socket.c:2624 [inline]<br /> __do_sys_sendmsg net/socket.c:2633 [inline]<br /> __se_sys_sendmsg net/socket.c:2631 [inline]<br /> __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> TIPC bearer-related names including link names must be null-terminated<br /> strings. If a link name which is not null-terminated is passed through<br /> netlink, strstr() and similar functions can cause buffer overrun. This<br /> causes the above issue.<br /> <br /> This patch changes the nla_policy for bearer-related names from NLA_STRING<br /> to NLA_NUL_STRING. This resolves the issue by ensuring that only<br /> null-terminated strings are accepted as bearer-related names.<br /> <br /> syzbot reported similar uninit-value issue related to bearer names [2]. The<br /> root cause of this issue is that a non-null-terminated bearer name was<br /> passed. This patch also resolved this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Prevent use after free in prp_create_tagged_frame()<br /> <br /> The prp_fill_rct() function can fail. In that situation, it frees the<br /> skb and returns NULL. Meanwhile on the success path, it returns the<br /> original skb. So it&amp;#39;s straight forward to fix bug by using the returned<br /> value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: bttv: fix use after free error due to btv-&gt;timeout timer<br /> <br /> There may be some a race condition between timer function<br /> bttv_irq_timeout and bttv_remove. The timer is setup in<br /> probe and there is no timer_delete operation in remove<br /> function. When it hit kfree btv, the function might still be<br /> invoked, which will cause use after free bug.<br /> <br /> This bug is found by static analysis, it may be false positive.<br /> <br /> Fix it by adding del_timer_sync invoking to the remove function.<br /> <br /> cpu0 cpu1<br /> bttv_probe<br /> -&gt;timer_setup<br /> -&gt;bttv_set_dma<br /> -&gt;mod_timer;<br /> bttv_remove<br /> -&gt;kfree(btv);<br /> -&gt;bttv_irq_timeout<br /> -&gt;USE btv

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to drop meta_inode&amp;#39;s page cache in f2fs_put_super()<br /> <br /> syzbot reports a kernel bug as below:<br /> <br /> F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1<br /> kernel BUG at fs/f2fs/super.c:1639!<br /> CPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0<br /> RIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639<br /> Call Trace:<br /> generic_shutdown_super+0x161/0x3c0 fs/super.c:693<br /> kill_block_super+0x3b/0x70 fs/super.c:1646<br /> kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879<br /> deactivate_locked_super+0x9a/0x170 fs/super.c:481<br /> deactivate_super+0xde/0x100 fs/super.c:514<br /> cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254<br /> task_work_run+0x14d/0x240 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296<br /> do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> In f2fs_put_super(), it tries to do sanity check on dirty and IO<br /> reference count of f2fs, once there is any reference count leak,<br /> it will trigger panic.<br /> <br /> The root case is, during f2fs_put_super(), if there is any IO error<br /> in f2fs_wait_on_all_pages(), we missed to truncate meta_inode&amp;#39;s page<br /> cache later, result in panic, fix this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: fix a possible null pointer dereference<br /> <br /> In versatile_panel_get_modes(), the return value of drm_mode_duplicate()<br /> is assigned to mode, which will lead to a NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.