Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: xsk: rx: fix the frame&amp;#39;s length check<br /> <br /> When calling buf_to_xdp, the len argument is the frame data&amp;#39;s length<br /> without virtio header&amp;#39;s length (vi-&gt;hdr_len). We check that len with<br /> <br /> xsk_pool_get_rx_frame_size() + vi-&gt;hdr_len<br /> <br /> to ensure the provided len does not larger than the allocated chunk<br /> size. The additional vi-&gt;hdr_len is because in virtnet_add_recvbuf_xsk,<br /> we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost<br /> to start placing data from<br /> <br /> hard_start + XDP_PACKET_HEADROOM - vi-&gt;hdr_len<br /> not<br /> hard_start + XDP_PACKET_HEADROOM<br /> <br /> But the first buffer has virtio_header, so the maximum frame&amp;#39;s length in<br /> the first buffer can only be<br /> <br /> xsk_pool_get_rx_frame_size()<br /> not<br /> xsk_pool_get_rx_frame_size() + vi-&gt;hdr_len<br /> <br /> like in the current check.<br /> <br /> This commit adds an additional argument to buf_to_xdp differentiate<br /> between the first buffer and other ones to correctly calculate the maximum<br /> frame&amp;#39;s length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850<br /> <br /> GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash<br /> on some specific platforms.<br /> <br /> Since this register is divergent for WCN7850 and QCN9274, move it to<br /> register table to allow different definitions. Then correct the register<br /> address for WCN7850 to fix this issue.<br /> <br /> Note IPQ5332 is not affected as it is not PCIe based device.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix eswitch code memory leak in reset scenario<br /> <br /> Add simple eswitch mode checker in attaching VF procedure and allocate<br /> required port representor memory structures only in switchdev mode.<br /> The reset flows triggers VF (if present) detach/attach procedure.<br /> It might involve VF port representor(s) re-creation if the device is<br /> configured is switchdev mode (not legacy one).<br /> The memory was blindly allocated in current implementation,<br /> regardless of the mode and not freed if in legacy mode.<br /> <br /> Kmemeleak trace:<br /> unreferenced object (percpu) 0x7e3bce5b888458 (size 40):<br /> comm "bash", pid 1784, jiffies 4295743894<br /> hex dump (first 32 bytes on cpu 45):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 0):<br /> pcpu_alloc_noprof+0x4c4/0x7c0<br /> ice_repr_create+0x66/0x130 [ice]<br /> ice_repr_create_vf+0x22/0x70 [ice]<br /> ice_eswitch_attach_vf+0x1b/0xa0 [ice]<br /> ice_reset_all_vfs+0x1dd/0x2f0 [ice]<br /> ice_pci_err_resume+0x3b/0xb0 [ice]<br /> pci_reset_function+0x8f/0x120<br /> reset_store+0x56/0xa0<br /> kernfs_fop_write_iter+0x120/0x1b0<br /> vfs_write+0x31c/0x430<br /> ksys_write+0x61/0xd0<br /> do_syscall_64+0x5b/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Testing hints (ethX is PF netdev):<br /> - create at least one VF<br /> echo 1 &gt; /sys/class/net/ethX/device/sriov_numvfs<br /> - trigger the reset<br /> echo 1 &gt; /sys/class/net/ethX/device/reset

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks<br /> <br /> After retrieving WMI data blocks in sysfs callbacks, check for the<br /> validity of them before dereferencing their content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: remove WARN on bad firmware input<br /> <br /> If the firmware gives bad input, that&amp;#39;s nothing to do with<br /> the driver&amp;#39;s stack at this point etc., so the WARN_ON()<br /> doesn&amp;#39;t add any value. Additionally, this is one of the<br /> top syzbot reports now. Just print a message, and as an<br /> added bonus, print the sizes too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix another leak in the submit error path<br /> <br /> put_unused_fd() doesn&amp;#39;t free the installed file, if we&amp;#39;ve already done<br /> fd_install(). So we need to also free the sync_file.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/653583/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix a fence leak in submit error path<br /> <br /> In error paths, we could unref the submit without calling<br /> drm_sched_entity_push_job(), so msm_job_free() will never get<br /> called. Since drm_sched_job_cleanup() will NULL out the<br /> s_fence, we can use that to detect this case.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/653584/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix memory leak of bio integrity<br /> <br /> If nvmet receives commands with metadata there is a continuous memory<br /> leak of kmalloc-128 slab or more precisely bio-&gt;bi_integrity.<br /> <br /> Since commit bf4c89fc8797 ("block: don&amp;#39;t call bio_uninit from bio_endio")<br /> each user of bio_init has to use bio_uninit as well. Otherwise the bio<br /> integrity is not getting free. Nvmet uses bio_init for inline bios.<br /> <br /> Uninit the inline bio to complete deallocation of integrity in bio.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: cpu_ops_sbi: Use static array for boot_data<br /> <br /> Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk<br /> allocator"), if NUMA is enabled, the page percpu allocator may be used<br /> on very sparse configurations, or when requested on boot with<br /> percpu_alloc=page.<br /> <br /> In that case, percpu data gets put in the vmalloc area. However,<br /> sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,<br /> and simply assumes that __pa() would work. This causes the just started<br /> hart to immediately access an invalid address and hang.<br /> <br /> Fortunately, struct sbi_hart_boot_data is not too large, so we can<br /> simply allocate an array for boot_data statically, putting it in the<br /> kernel image.<br /> <br /> This fixes NUMA=y SMP boot on Sophgo SG2042.<br /> <br /> To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then<br /> run with:<br /> <br /> qemu-system-riscv64 -M virt -smp 2 -nographic \<br /> -kernel arch/riscv/boot/Image \<br /> -append "percpu_alloc=page"<br /> <br /> Kernel output:<br /> <br /> [ 0.000000] Booting Linux on hartid 0<br /> [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025<br /> ...<br /> [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712<br /> ...<br /> [ 0.083192] smp: Bringing up secondary CPUs ...<br /> [ 0.086722] ------------[ cut here ]------------<br /> [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)<br /> [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8<br /> [ 0.088376] Modules linked in:<br /> [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE<br /> [ 0.088833] Hardware name: riscv-virtio,qemu (DT)<br /> [ 0.088948] epc : __virt_to_phys+0xae/0xe8<br /> [ 0.089001] ra : __virt_to_phys+0xae/0xe8<br /> [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0<br /> [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976<br /> [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0<br /> [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000<br /> [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000<br /> [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001<br /> [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec<br /> [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000<br /> [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7<br /> [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8<br /> [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003<br /> [ 0.090101] [] __virt_to_phys+0xae/0xe8<br /> [ 0.090228] [] sbi_cpu_start+0x6e/0xe8<br /> [ 0.090247] [] __cpu_up+0x1e/0x8c<br /> [ 0.090260] [] bringup_cpu+0x42/0x258<br /> [ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c<br /> [ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc<br /> [ 0.090320] [] _cpu_up+0x11a/0x244<br /> [ 0.090334] [] cpu_up+0x52/0x90<br /> [ 0.090384] [] bringup_nonboot_cpus+0x78/0x118<br /> [ 0.090411] [] smp_init+0x34/0xb8<br /> [ 0.090425] [] kernel_init_freeable+0x148/0x2e4<br /> [ 0.090442] [] kernel_init+0x1e/0x14c<br /> [ 0.090455] [] ret_from_fork_kernel+0xe/0xf0<br /> [ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18<br /> [ 0.090560] ---[ end trace 0000000000000000 ]---<br /> [ 1.179875] CPU1: failed to come online<br /> [ 1.190324] smp: Brought up 1 node, 1 CPU

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix double put of request<br /> <br /> If a netfs request finishes during the pause loop, it will have the ref<br /> that belongs to the IN_PROGRESS flag removed at that point - however, if it<br /> then goes to the final wait loop, that will *also* put the ref because it<br /> sees that the IN_PROGRESS flag is clear and incorrectly assumes that this<br /> happened when it called the collector.<br /> <br /> In fact, since IN_PROGRESS is clear, we shouldn&amp;#39;t call the collector again<br /> since it&amp;#39;s done all the cleanup, such as calling -&gt;ki_complete().<br /> <br /> Fix this by making netfs_collect_in_app() just return, indicating that<br /> we&amp;#39;re done if IN_PROGRESS is removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/irq_sim: Initialize work context pointers properly<br /> <br /> Initialize `ops` member&amp;#39;s pointers properly by using kzalloc() instead of<br /> kmalloc() when allocating the simulation work context. Otherwise the<br /> pointers contain random content leading to invalid dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/vmci: Clear the vmci transport packet properly when initializing it<br /> <br /> In vmci_transport_packet_init memset the vmci_transport_packet before<br /> populating the fields to avoid any uninitialised data being left in the<br /> structure.