Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Increment job count before swapping tail spsc queue<br /> <br /> A small race exists between spsc_queue_push and the run-job worker, in<br /> which spsc_queue_push may return not-first while the run-job worker has<br /> already idled due to the job count being zero. If this race occurs, job<br /> scheduling stops, leading to hangs while waiting on the job’s DMA<br /> fences.<br /> <br /> Seal this race by incrementing the job count before appending to the<br /> SPSC queue.<br /> <br /> This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in<br /> an SVM test case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: qcom: msm: mark certain pins as invalid for interrupts<br /> <br /> On some platforms, the UFS-reset pin has no interrupt logic in TLMM but<br /> is nevertheless registered as a GPIO in the kernel. This enables the<br /> user-space to trigger a BUG() in the pinctrl-msm driver by running, for<br /> example: `gpiomon -c 0 113` on RB2.<br /> <br /> The exact culprit is requesting pins whose intr_detection_width setting<br /> is not 1 or 2 for interrupts. This hits a BUG() in<br /> msm_gpio_irq_set_type(). Potentially crashing the kernel due to an<br /> invalid request from user-space is not optimal, so let&amp;#39;s go through the<br /> pins and mark those that would fail the check as invalid for the irq chip<br /> as we should not even register them as available irqs.<br /> <br /> This function can be extended if we determine that there are more<br /> corner-cases like this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()<br /> <br /> alloc_tag_top_users() attempts to lock alloc_tag_cttype-&gt;mod_lock even<br /> when the alloc_tag_cttype is not allocated because:<br /> <br /> 1) alloc tagging is disabled because mem profiling is disabled<br /> (!alloc_tag_cttype)<br /> 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)<br /> 3) alloc tagging is enabled, but failed initialization<br /> (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))<br /> <br /> In all cases, alloc_tag_cttype is not allocated, and therefore<br /> alloc_tag_top_users() should not attempt to acquire the semaphore.<br /> <br /> This leads to a crash on memory allocation failure by attempting to<br /> acquire a non-existent semaphore:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]<br /> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY<br /> Tainted: [D]=DIE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:down_read_trylock+0xaa/0x3b0<br /> Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff<br /> RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016<br /> RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000<br /> RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070<br /> RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1<br /> R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37<br /> R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000<br /> FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> codetag_trylock_module_list+0xd/0x20<br /> alloc_tag_top_users+0x369/0x4b0<br /> __show_mem+0x1cd/0x6e0<br /> warn_alloc+0x2b1/0x390<br /> __alloc_frozen_pages_noprof+0x12b9/0x21a0<br /> alloc_pages_mpol+0x135/0x3e0<br /> alloc_slab_page+0x82/0xe0<br /> new_slab+0x212/0x240<br /> ___slab_alloc+0x82a/0xe00<br /> <br /> <br /> As David Wang points out, this issue became easier to trigger after commit<br /> 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init").<br /> <br /> Before the commit, the issue occurred only when it failed to allocate and<br /> initialize alloc_tag_cttype or if a memory allocation fails before<br /> alloc_tag_init() is called. After the commit, it can be easily triggered<br /> when memory profiling is compiled but disabled at boot.<br /> <br /> To properly determine whether alloc_tag_init() has been called and its<br /> data structures initialized, verify that alloc_tag_cttype is a valid<br /> pointer before acquiring the semaphore. If the variable is NULL or an<br /> error value, it has not been properly initialized. In such a case, just<br /> skip and do not attempt to acquire the semaphore.<br /> <br /> [harry.yoo@oracle.com: v3]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix pp destruction warnings<br /> <br /> With multiple page pools and in some other cases we can have allocated<br /> niovs on page pool destruction. Remove a misplaced warning checking that<br /> all niovs are returned to zcrx on io_pp_zc_destroy(). It was reported<br /> before but apparently got lost.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: discard erroneous disassoc frames on STA interface<br /> <br /> When operating in concurrent STA/AP mode with host MLME enabled,<br /> the firmware incorrectly sends disassociation frames to the STA<br /> interface when clients disconnect from the AP interface.<br /> This causes kernel warnings as the STA interface processes<br /> disconnect events that don&amp;#39;t apply to it:<br /> <br /> [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211]<br /> [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us<br /> [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT<br /> [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)<br /> [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]<br /> [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211]<br /> [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211]<br /> [ 1303.370221] sp : ffff800083053be0<br /> [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae<br /> [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008<br /> [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006<br /> [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048<br /> [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000<br /> [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300<br /> [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002<br /> [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186<br /> [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de<br /> [ 1303.446221] Call trace:<br /> [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P)<br /> [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211]<br /> [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex]<br /> [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex]<br /> [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex]<br /> [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex]<br /> [ 1303.483734] process_one_work+0x14c/0x28c<br /> [ 1303.487845] worker_thread+0x2cc/0x3d4<br /> [ 1303.491680] kthread+0x12c/0x208<br /> [ 1303.495014] ret_from_fork+0x10/0x20<br /> <br /> Add validation in the STA receive path to verify that disassoc/deauth<br /> frames originate from the connected AP. Frames that fail this check<br /> are discarded early, preventing them from reaching the MLME layer and<br /> triggering WARN_ON().<br /> <br /> This filtering logic is similar with that used in the<br /> ieee80211_rx_mgmt_disassoc() function in mac80211, which drops<br /> disassoc frames that don&amp;#39;t match the current BSSID<br /> (!ether_addr_equal(mgmt-&gt;bssid, sdata-&gt;vif.cfg.ap_addr)), ensuring<br /> only relevant frames are processed.<br /> <br /> Tested on:<br /> - 8997 with FW 16.68.1.p197

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Allow CPU to reschedule while setting per-page memory attributes<br /> <br /> When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),<br /> the host can experience CPU soft lockups when running an operation in<br /> kvm_vm_set_mem_attributes() to set memory attributes on the whole<br /> range of guest memory.<br /> <br /> watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]<br /> CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)<br /> Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024<br /> RIP: 0010:xas_create+0x78/0x1f0<br /> Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87<br /> RSP: 0018:ffffad890a34b940 EFLAGS: 00000286<br /> RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000<br /> RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868<br /> R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868<br /> FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> xas_store+0x58/0x630<br /> __xa_store+0xa5/0x130<br /> xa_store+0x2c/0x50<br /> kvm_vm_set_mem_attributes+0x343/0x710 [kvm]<br /> kvm_vm_ioctl+0x796/0xab0 [kvm]<br /> __x64_sys_ioctl+0xa3/0xd0<br /> do_syscall_64+0x8c/0x7a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f5578d031bb<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb<br /> RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b<br /> RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000<br /> R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120<br /> R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0<br /> <br /> While looping through the range of memory setting the attributes,<br /> call cond_resched() to give the scheduler a chance to run a higher<br /> priority task on the runqueue if necessary and avoid staying in<br /> kernel mode long enough to trigger the lockup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: nintendo: avoid bluetooth suspend/resume stalls<br /> <br /> Ensure we don&amp;#39;t stall or panic the kernel when using bluetooth-connected<br /> controllers. This was reported as an issue on android devices using<br /> kernel 6.6 due to the resume hook which had been added for usb joycons.<br /> <br /> First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a<br /> newly-added nintendo_hid_suspend. This makes sure we will not stall out<br /> the kernel waiting for input reports during led classdev suspend. The<br /> stalls could happen if connectivity is unreliable or lost to the<br /> controller prior to suspend.<br /> <br /> Second, since we lose connectivity during suspend, do not try<br /> joycon_init() for bluetooth controllers in the nintendo_hid_resume path.<br /> <br /> Tested via multiple suspend/resume flows when using the controller both<br /> in USB and bluetooth modes.

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.