Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Fix coverity issue with unintentional integer overflow<br /> <br /> 1. Instead of multiplying 2 variable of different types. Change to<br /> assign a value of one variable and then multiply the other variable.<br /> <br /> 2. Add a int variable for multiplier calculation instead of calculating<br /> different types multiplier with dma_addr_t variable directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Bail out early if the request AUX area is out of bound<br /> <br /> When perf-record with a large AUX area, e.g 4GB, it fails with:<br /> <br /> #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1<br /> failed to mmap with 12 (Cannot allocate memory)<br /> <br /> and it reveals a WARNING with __alloc_pages():<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248<br /> Call trace:<br /> __alloc_pages+0x1ec/0x248<br /> __kmalloc_large_node+0xc0/0x1f8<br /> __kmalloc_node+0x134/0x1e8<br /> rb_alloc_aux+0xe0/0x298<br /> perf_mmap+0x440/0x660<br /> mmap_region+0x308/0x8a8<br /> do_mmap+0x3c0/0x528<br /> vm_mmap_pgoff+0xf4/0x1b8<br /> ksys_mmap_pgoff+0x18c/0x218<br /> __arm64_sys_mmap+0x38/0x58<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x58/0x188<br /> do_el0_svc+0x34/0x50<br /> el0_svc+0x34/0x108<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x1a4/0x1a8<br /> <br /> &amp;#39;rb-&gt;aux_pages&amp;#39; allocated by kcalloc() is a pointer array which is used to<br /> maintains AUX trace pages. The allocated page for this array is physically<br /> contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the<br /> size of pointer array crosses the limitation set by MAX_ORDER, it reveals a<br /> WARNING.<br /> <br /> So bail out early with -ENOMEM if the request AUX area is out of bound,<br /> e.g.:<br /> <br /> #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1<br /> failed to mmap with 12 (Cannot allocate memory)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/ww_mutex/test: Fix potential workqueue corruption<br /> <br /> In some cases running with the test-ww_mutex code, I was seeing<br /> odd behavior where sometimes it seemed flush_workqueue was<br /> returning before all the work threads were finished.<br /> <br /> Often this would cause strange crashes as the mutexes would be<br /> freed while they were being used.<br /> <br /> Looking at the code, there is a lifetime problem as the<br /> controlling thread that spawns the work allocates the<br /> "struct stress" structures that are passed to the workqueue<br /> threads. Then when the workqueue threads are finished,<br /> they free the stress struct that was passed to them.<br /> <br /> Unfortunately the workqueue work_struct node is in the stress<br /> struct. Which means the work_struct is freed before the work<br /> thread returns and while flush_workqueue is waiting.<br /> <br /> It seems like a better idea to have the controlling thread<br /> both allocate and free the stress structures, so that we can<br /> be sure we don&amp;#39;t corrupt the workqueue by freeing the structure<br /> prematurely.<br /> <br /> So this patch reworks the test to do so, and with this change<br /> I no longer see the early flush_workqueue returns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix uaf in nbd_open<br /> <br /> Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and<br /> blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won&amp;#39;t set<br /> disk-&gt;private_data as NULL as before. UAF may be triggered in nbd_open()<br /> if someone tries to open nbd device right after nbd_put() since nbd has<br /> been free in nbd_dev_remove().<br /> <br /> Fix this by implementing -&gt;free_disk and free private data in it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: imsttfb: fix a resource leak in probe<br /> <br /> I&amp;#39;ve re-written the error handling but the bug is that if init_imstt()<br /> fails we need to call iounmap(par-&gt;cmap_regs).

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.