Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: increase scan_ies_len for S1G<br /> <br /> Currently the S1G capability element is not taken into account<br /> for the scan_ies_len, which leads to a buffer length validation<br /> failure in ieee80211_prep_hw_scan() and subsequent WARN in<br /> __ieee80211_start_scan(). This prevents hw scanning from functioning.<br /> To fix ensure we accommodate for the S1G capability length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Make attach succeed when the device was surprise removed<br /> <br /> When a PCI device is removed with surprise hotplug, there may still be<br /> attempts to attach the device to the default domain as part of tear down<br /> via (__iommu_release_dma_ownership()), or because the removal happens<br /> during probe (__iommu_probe_device()). In both cases zpci_register_ioat()<br /> fails with a cc value indicating that the device handle is invalid. This<br /> is because the device is no longer part of the instance as far as the<br /> hypervisor is concerned.<br /> <br /> Currently this leads to an error return and s390_iommu_attach_device()<br /> fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()<br /> because attaching to the default domain must never fail.<br /> <br /> With the device fenced by the hypervisor no DMAs to or from memory are<br /> possible and the IOMMU translations have no effect. Proceed as if the<br /> registration was successful and let the hotplug event handling clean up<br /> the device.<br /> <br /> This is similar to how devices in the error state are handled since<br /> commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device<br /> is in error state") except that for removal the domain will not be<br /> registered later. This approach was also previously discussed at the<br /> link.<br /> <br /> Handle both cases, error state and removal, in a helper which checks if<br /> the error needs to be propagated or ignored. Avoid magic number<br /> condition codes by using the pre-existing, but never used, defines for<br /> PCI load/store condition codes and rename them to reflect that they<br /> apply to all PCI instructions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Clear tcp_sk(sk)-&gt;fastopen_rsk in tcp_disconnect().<br /> <br /> syzbot reported the splat below where a socket had tcp_sk(sk)-&gt;fastopen_rsk<br /> in the TCP_ESTABLISHED state. [0]<br /> <br /> syzbot reused the server-side TCP Fast Open socket as a new client before<br /> the TFO socket completes 3WHS:<br /> <br /> 1. accept()<br /> 2. connect(AF_UNSPEC)<br /> 3. connect() to another destination<br /> <br /> As of accept(), sk-&gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes<br /> it to TCP_CLOSE and makes connect() possible, which restarts timers.<br /> <br /> Since tcp_disconnect() forgot to clear tcp_sk(sk)-&gt;fastopen_rsk, the<br /> retransmit timer triggered the warning and the intended packet was not<br /> retransmitted.<br /> <br /> Let&amp;#39;s call reqsk_fastopen_remove() in tcp_disconnect().<br /> <br /> [0]:<br /> WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))<br /> Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e<br /> RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293<br /> RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017<br /> RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400<br /> RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8<br /> R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540<br /> R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0<br /> FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> tcp_write_timer (net/ipv4/tcp_timer.c:738)<br /> call_timer_fn (kernel/time/timer.c:1747)<br /> __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)<br /> timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)<br /> tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)<br /> __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))<br /> tmigr_handle_remote (kernel/time/timer_migration.c:1096)<br /> handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)<br /> irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: don&amp;#39;t fail igc_probe() on LED setup error<br /> <br /> When igc_led_setup() fails, igc_probe() fails and triggers kernel panic<br /> in free_netdev() since unregister_netdev() is not called. [1]<br /> This behavior can be tested using fault-injection framework, especially<br /> the failslab feature. [2]<br /> <br /> Since LED support is not mandatory, treat LED setup failures as<br /> non-fatal and continue probe with a warning message, consequently<br /> avoiding the kernel panic.<br /> <br /> [1]<br /> kernel BUG at net/core/dev.c:12047!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:free_netdev+0x278/0x2b0<br /> [...]<br /> Call Trace:<br /> <br /> igc_probe+0x370/0x910<br /> local_pci_probe+0x3a/0x80<br /> pci_device_probe+0xd1/0x200<br /> [...]<br /> <br /> [2]<br /> #!/bin/bash -ex<br /> <br /> FAILSLAB_PATH=/sys/kernel/debug/failslab/<br /> DEVICE=0000:00:05.0<br /> START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \<br /> | awk &amp;#39;{printf("0x%s", $1)}&amp;#39;)<br /> END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100)))<br /> <br /> echo $START_ADDR &gt; $FAILSLAB_PATH/require-start<br /> echo $END_ADDR &gt; $FAILSLAB_PATH/require-end<br /> echo 1 &gt; $FAILSLAB_PATH/times<br /> echo 100 &gt; $FAILSLAB_PATH/probability<br /> echo N &gt; $FAILSLAB_PATH/ignore-gfp-wait<br /> <br /> echo $DEVICE &gt; /sys/bus/pci/drivers/igc/bind

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: sunxi-ng: mp: Fix dual-divider clock rate readback<br /> <br /> When dual-divider clock support was introduced, the P divider offset was<br /> left out of the .recalc_rate readback function. This causes the clock<br /> rate to become bogus or even zero (possibly due to the P divider being<br /> 1, leading to a divide-by-zero).<br /> <br /> Fix this by incorporating the P divider offset into the calculation.

The Popup builder with Gamification, Multi-Step Popups, Page-Level Targeting, and WooCommerce Triggers plugin for WordPress is vulnerable to SQL Injection in all versions up to, and including, 2.1.3. This is due to insufficient escaping on the &amp;#39;id&amp;#39; parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The Search &amp; Go - Directory WordPress Theme theme for WordPress is vulnerable to Authentication Bypass via account takeover in all versions up to, and including, 2.7. This is due to insufficient user validation in the search_and_go_elated_check_facebook_user() function This makes it possible for unauthenticated attackers to gain access to other user&amp;#39;s accounts, including administrators, when Facebook login is enabled. CVE-2025-62064 is likely a duplicate of this CVE.

Grafana Image Renderer is vulnerable to remote code execution due to an arbitrary file write vulnerability. This is due to the fact that the /render/csv endpoint lacked validation of the filePath parameter that allowed an attacker to save a shared object to an arbitrary location that is then loaded by the Chromium process.<br /> <br /> Instances are vulnerable if:<br /> <br /> 1. The default token ("authToken") is not changed, or is known to the attacker.<br /> 2. The attacker can reach the image renderer endpoint.<br /> This issue affects grafana-image-renderer: from 1.0.0 through 4.0.16.

The WP Travel Engine – Tour Booking Plugin – Tour Operator Software plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 6.6.7 via the mode parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included.

The WP Travel Engine – Tour Booking Plugin – Tour Operator Software plugin for WordPress is vulnerable to arbitrary file deletion (via renaming) due to insufficient file path validation in the set_user_profile_image function in all versions up to, and including, 6.6.7. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).

Memory corruption while invoking remote procedure IOCTL calls.

Memory corruption while allocating buffers in DSP service.