Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sev: Use TSC_FACTOR for Secure TSC frequency calculation<br /> <br /> When using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on<br /> the nominal P0 frequency, which deviates slightly (typically ~0.2%) from<br /> the actual mean TSC frequency due to clocking parameters.<br /> <br /> Over extended VM uptime, this discrepancy accumulates, causing clock skew<br /> between the hypervisor and a SEV-SNP VM, leading to early timer interrupts as<br /> perceived by the guest.<br /> <br /> The guest kernel relies on the reported nominal frequency for TSC-based<br /> timekeeping, while the actual frequency set during SNP_LAUNCH_START may<br /> differ. This mismatch results in inaccurate time calculations, causing the<br /> guest to perceive hrtimers as firing earlier than expected.<br /> <br /> Utilize the TSC_FACTOR from the SEV firmware&amp;#39;s secrets page (see "Secrets<br /> Page Format" in the SNP Firmware ABI Specification) to calculate the mean<br /> TSC frequency, ensuring accurate timekeeping and mitigating clock skew in<br /> SEV-SNP VMs.<br /> <br /> Use early_ioremap_encrypted() to map the secrets page as<br /> ioremap_encrypted() uses kmalloc() which is not available during early TSC<br /> initialization and causes a panic.<br /> <br /> [ bp: Drop the silly dummy var:<br /> https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: reject VHT opmode for unsupported channel widths<br /> <br /> VHT operating mode notifications are not defined for channel widths<br /> below 20 MHz. In particular, 5 MHz and 10 MHz are not valid under the<br /> VHT specification and must be rejected.<br /> <br /> Without this check, malformed notifications using these widths may<br /> reach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due to<br /> invalid input. This issue was reported by syzbot.<br /> <br /> Reject these unsupported widths early in sta_link_apply_parameters()<br /> when opmode_notif is used. The accepted set includes 20, 40, 80, 160,<br /> and 80+80 MHz, which are valid for VHT. While 320 MHz is not defined<br /> for VHT, it is allowed to avoid rejecting HE or EHT clients that may<br /> still send a VHT opmode notification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix assertion when building free space tree<br /> <br /> When building the free space tree with the block group tree feature<br /> enabled, we can hit an assertion failure like this:<br /> <br /> BTRFS info (device loop0 state M): rebuilding free space tree<br /> assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/free-space-tree.c:1102!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102<br /> lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102<br /> sp : ffff8000a4ce7600<br /> x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8<br /> x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001<br /> x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160<br /> x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff<br /> x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0<br /> x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff<br /> x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00<br /> x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0<br /> x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e<br /> Call trace:<br /> populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)<br /> btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337<br /> btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074<br /> btrfs_remount_rw fs/btrfs/super.c:1319 [inline]<br /> btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543<br /> reconfigure_super+0x1d4/0x6f0 fs/super.c:1083<br /> do_remount fs/namespace.c:3365 [inline]<br /> path_mount+0xb34/0xde0 fs/namespace.c:4200<br /> do_mount fs/namespace.c:4221 [inline]<br /> __do_sys_mount fs/namespace.c:4432 [inline]<br /> __se_sys_mount fs/namespace.c:4409 [inline]<br /> __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> Code: f0047182 91178042 528089c3 9771d47b (d4210000)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because we are processing an empty block group, which has<br /> no extents allocated from it, there are no items for this block group,<br /> including the block group item since block group items are stored in a<br /> dedicated tree when using the block group tree feature. It also means<br /> this is the block group with the highest start offset, so there are no<br /> higher keys in the extent root, hence btrfs_search_slot_for_read()<br /> returns 1 (no higher key found).<br /> <br /> Fix this by asserting &amp;#39;ret&amp;#39; is 0 only if the block group tree feature<br /> is not enabled, in which case we should find a block group item for<br /> the block group since it&amp;#39;s stored in the extent root and block group<br /> item keys are greater than extent item keys (the value for<br /> BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and<br /> BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).<br /> In case &amp;#39;ret&amp;#39; is 1, we just need to add a record to the free space<br /> tree which spans the whole block group, and we can achieve this by<br /> making &amp;#39;ret == 0&amp;#39; as the while loop&amp;#39;s condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix oob access in cgroup local storage<br /> <br /> Lonial reported that an out-of-bounds access in cgroup local storage<br /> can be crafted via tail calls. Given two programs each utilizing a<br /> cgroup local storage with a different value size, and one program<br /> doing a tail call into the other. The verifier will validate each of<br /> the indivial programs just fine. However, in the runtime context<br /> the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the<br /> BPF program as well as any cgroup local storage flavor the program<br /> uses. Helpers such as bpf_get_local_storage() pick this up from the<br /> runtime context:<br /> <br /> ctx = container_of(current-&gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);<br /> storage = ctx-&gt;prog_item-&gt;cgroup_storage[stype];<br /> <br /> if (stype == BPF_CGROUP_STORAGE_SHARED)<br /> ptr = &amp;READ_ONCE(storage-&gt;buf)-&gt;data[0];<br /> else<br /> ptr = this_cpu_ptr(storage-&gt;percpu_buf);<br /> <br /> For the second program which was called from the originally attached<br /> one, this means bpf_get_local_storage() will pick up the former<br /> program&amp;#39;s map, not its own. With mismatching sizes, this can result<br /> in an unintended out-of-bounds access.<br /> <br /> To fix this issue, we need to extend bpf_map_owner with an array of<br /> storage_cookie[] to match on i) the exact maps from the original<br /> program if the second program was using bpf_get_local_storage(), or<br /> ii) allow the tail call combination if the second program was not<br /> using any of the cgroup local storage maps.

The Translate This gTranslate Shortcode plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘base_lang’ parameter in all versions up to, and including, 1.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Drag and Drop Multiple File Upload for Contact Form 7 plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 1.3.9.0 via the wpcf7_guest_user_id cookie. This makes it possible for unauthenticated attackers to upload and delete files outside of the originally intended directory. The impact of this vulnerability is limited, as file types are validated and only safe ones can be uploaded, while deletion is limited to the plugin&amp;#39;s uploads folder.

The BetterDocs – Advanced AI-Driven Documentation, FAQ &amp; Knowledge Base Tool for Elementor &amp; Gutenberg with Encyclopedia, AI Support, Instant Answers plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the get_response function in all versions up to and including 4.1.1. This makes it possible for unauthenticated attackers to retrieve passwords for password-protected documents as well as the metadata of private and draft documents.

The Taxi Booking Manager for Woocommerce | E-cab plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 1.3.0. This is due to the plugin not properly validating a user&amp;#39;s capabilities prior to updating a plugin setting or their identity prior to updating their details like email address. This makes it possible for unauthenticated attackers to change arbitrary user&amp;#39;s email addresses, including administrators, and leverage that to reset the user&amp;#39;s password and gain access to their account.

The Advanced iFrame plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the &amp;#39;additional&amp;#39; parameter in version less than, or equal to, 2025.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The User Profile Builder – Beautiful User Registration Forms, User Profiles &amp; User Role Editor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the &amp;#39;gdpr_communication_preferences[]&amp;#39; parameter in all versions up to, and including, 3.14.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is only exploitable when the GDPR Communication Preferences module is enabled and at least one GDPR Communication Preferences field has been added to the edit profile form.

The Ebook Store WordPress plugin before 5.8015 does not escape the $_SERVER[&amp;#39;REQUEST_URI&amp;#39;] parameter before outputting it back in an attribute, which could lead to Reflected Cross-Site Scripting in old web browsers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: limit repeated connections from clients with the same IP<br /> <br /> Repeated connections from clients with the same IP address may exhaust<br /> the max connections and prevent other normal client connections.<br /> This patch limit repeated connections from clients with the same IP.