Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: ring-buffer: Fix to check event length before using<br /> <br /> Check the event length before adding it for accessing next index in<br /> rb_read_data_buffer(). Since this function is used for validating<br /> possibly broken ring buffers, the length of the event could be broken.<br /> In that case, the new event (e + len) can point a wrong address.<br /> To avoid invalid memory access at boot, check whether the length of<br /> each event is in the possible range before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-mdp: Fix error handling in probe function<br /> <br /> Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent<br /> resource leak.<br /> <br /> Add check for the return value of vpu_get_plat_device() to prevent null<br /> pointer dereference. And vpu_get_plat_device() increases the reference<br /> count of the returned platform device. Add platform_device_put() to<br /> prevent reference leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not pass flow_id to set_rps_cpu()<br /> <br /> Blamed commit made the assumption that the RPS table for each receive<br /> queue would have the same size, and that it would not change.<br /> <br /> Compute flow_id in set_rps_cpu(), do not assume we can use the value<br /> computed by get_rps_cpu(). Otherwise we risk out-of-bound access<br /> and/or crashes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix pci_slot_trylock() error handling<br /> <br /> Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")<br /> delegates the bridge device&amp;#39;s pci_dev_trylock() to pci_bus_trylock() in<br /> pci_slot_trylock(), but it forgets to remove the corresponding<br /> pci_dev_unlock() when pci_bus_trylock() fails.<br /> <br /> Before a4e772898f8b, the code did:<br /> <br /> if (!pci_dev_trylock(dev)) /* subordinate) {<br /> if (!pci_bus_trylock(dev-&gt;subordinate)) {<br /> pci_dev_unlock(dev); /*

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE<br /> <br /> The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -<br /> which is a valid index - so add a check for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: pci: validate sequence number of TX release report<br /> <br /> Hardware rarely reports abnormal sequence number in TX release report,<br /> which will access out-of-bounds of wd_ring-&gt;pages array, causing NULL<br /> pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U<br /> 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1)<br /> Call Trace:<br /> <br /> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)]<br /> rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)]<br /> net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759<br /> handle_softirqs+0xbe/0x290 kernel/softirq.c:601<br /> ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)]<br /> __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423<br /> <br /> <br /> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)]<br /> ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0<br /> irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314<br /> ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202<br /> ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220<br /> kthread+0xea/0x110 kernel/kthread.c:376<br /> ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287<br /> ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> <br /> To prevent crash, validate rpp_info.seq before using.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()<br /> <br /> Add SRCU read-side protection when reading PDPTR registers in<br /> __get_sregs2().<br /> <br /> Reading PDPTRs may trigger access to guest memory:<br /> kvm_pdptr_read() -&gt; svm_cache_reg() -&gt; load_pdptrs() -&gt;<br /> kvm_vcpu_read_guest_page() -&gt; kvm_vcpu_gfn_to_memslot()<br /> <br /> kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),<br /> which uses srcu_dereference_check() and requires either kvm-&gt;srcu or<br /> kvm-&gt;slots_lock to be held. Currently only vcpu-&gt;mutex is held,<br /> triggering lockdep warning:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot<br /> 6.12.59+ #3 Not tainted<br /> <br /> include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz.5.1717/15100:<br /> #0: ff1100002f4b00b0 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120<br /> lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824<br /> __kvm_memslots include/linux/kvm_host.h:1062 [inline]<br /> __kvm_memslots include/linux/kvm_host.h:1059 [inline]<br /> kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline]<br /> kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617<br /> kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302<br /> load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065<br /> svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688<br /> kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline]<br /> __get_sregs2 arch/x86/kvm/x86.c:11784 [inline]<br /> kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279<br /> kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions<br /> <br /> struct configfs_item_operations callbacks are defined like the following:<br /> <br /> int (*allow_link)(struct config_item *src, struct config_item *target);<br /> void (*drop_link)(struct config_item *src, struct config_item *target);<br /> <br /> While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify<br /> the parameters in the correct order, pci_primary_epc_epf_unlink() and<br /> pci_secondary_epc_epf_unlink() specify the parameters in the wrong order,<br /> leading to the below kernel crash when using the unlink command in<br /> configfs:<br /> <br /> Unable to handle kernel paging request at virtual address 0000000300000857<br /> Mem abort info:<br /> ...<br /> pc : string+0x54/0x14c<br /> lr : vsnprintf+0x280/0x6e8<br /> ...<br /> string+0x54/0x14c<br /> vsnprintf+0x280/0x6e8<br /> vprintk_default+0x38/0x4c<br /> vprintk+0xc4/0xe0<br /> pci_epf_unbind+0xdc/0x108<br /> configfs_unlink+0xe0/0x208+0x44/0x74<br /> vfs_unlink+0x120/0x29c<br /> __arm64_sys_unlinkat+0x3c/0x90<br /> invoke_syscall+0x48/0x134<br /> do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0<br /> <br /> [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> APEI/GHES: ARM processor Error: don&amp;#39;t go past allocated memory<br /> <br /> If the BIOS generates a very small ARM Processor Error, or<br /> an incomplete one, the current logic will fail to deferrence<br /> <br /> err-&gt;section_length<br /> and<br /> ctx_info-&gt;size<br /> <br /> Add checks to avoid that. With such changes, such GHESv2<br /> records won&amp;#39;t cause OOPSes like this:<br /> <br /> [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 1.495449] Modules linked in:<br /> [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT<br /> [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022<br /> [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred<br /> [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 1.497199] pc : log_arm_hw_error+0x5c/0x200<br /> [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220<br /> <br /> 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75).<br /> 70 err_info = (struct cper_arm_err_info *)(err + 1);<br /> 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err-&gt;err_info_num);<br /> 72 ctx_err = (u8 *)ctx_info;<br /> 73<br /> 74 for (n = 0; n context_info_num; n++) {<br /> 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info-&gt;size;<br /> 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);<br /> 77 ctx_len += sz;<br /> 78 }<br /> 79<br /> <br /> and similar ones while trying to access section_length on an<br /> error dump with too small size.<br /> <br /> [ rjw: Subject tweaks ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: vt8500lcdfb: fix missing dma_free_coherent()<br /> <br /> fbi-&gt;fb.screen_buffer is allocated with dma_alloc_coherent() but is not<br /> freed if the error path is reached.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6asm: drop DSP responses for closed data streams<br /> <br /> &amp;#39;Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses<br /> after closing")&amp;#39; attempted to ignore DSP responses arriving<br /> after a stream had been closed.<br /> <br /> However, those responses were still handled, causing lockups.<br /> <br /> Fix this by unconditionally dropping all DSP responses associated with<br /> closed data streams.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-switch: validate num_ifs to prevent out-of-bounds write<br /> <br /> The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()<br /> but never validates it against DPSW_MAX_IF (64). This value controls<br /> iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices<br /> into the fixed-size cfg-&gt;if_id[DPSW_MAX_IF] array. When firmware reports<br /> num_ifs &gt;= 64, the loop can write past the array bounds.<br /> <br /> Add a bound check for num_ifs in dpaa2_switch_init().<br /> <br /> dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port<br /> num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all<br /> ports match the flood filter, the loop fills all 64 slots and the control<br /> interface write overflows by one entry.<br /> <br /> The check uses &gt;= because num_ifs == DPSW_MAX_IF is also functionally<br /> broken.<br /> <br /> build_if_id_bitmap() silently drops any ID &gt;= 64:<br /> if (id[i]