Vulnerabilities

The AAWP Obfuscator plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'data-aawp-web' 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 Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Advanced Advertising System plugin for WordPress is vulnerable to Open Redirect in all versions up to, and including, 1.3.1. This is due to insufficient validation on the redirect url supplied via the 'redir' parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if they can successfully trick them into performing an action.

A vulnerability has been identified in Siemens License Server (SLS) (All versions

A vulnerability has been identified in Siemens License Server (SLS) (All versions

A vulnerability has been identified in Mendix Runtime V10 (All versions

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: fix xa_alloc_cyclic() error handling<br /> <br /> In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will<br /> be returned, which will cause IS_ERR() to be false. Which can lead to<br /> dereference not allocated pointer (rel).<br /> <br /> Fix it by checking if err is lower than zero.<br /> <br /> This wasn&amp;#39;t found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix xa_alloc_cyclic() error handling<br /> <br /> In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will<br /> be returned, which will cause IS_ERR() to be false. Which can lead to<br /> dereference not allocated pointer (pin).<br /> <br /> Fix it by checking if err is lower than zero.<br /> <br /> This wasn&amp;#39;t found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate: fix shmem xarray update during migration<br /> <br /> A shmem folio can be either in page cache or in swap cache, but not at the<br /> same time. Namely, once it is in swap cache, folio-&gt;mapping should be<br /> NULL, and the folio is no longer in a shmem mapping.<br /> <br /> In __folio_migrate_mapping(), to determine the number of xarray entries to<br /> update, folio_test_swapbacked() is used, but that conflates shmem in page<br /> cache case and shmem in swap cache case. It leads to xarray multi-index<br /> entry corruption, since it turns a sibling entry to a normal entry during<br /> xas_store() (see [1] for a userspace reproduction). Fix it by only using<br /> folio_test_swapcache() to determine whether xarray is storing swap cache<br /> entries or not to choose the right number of xarray entries to update.<br /> <br /> [1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/<br /> <br /> Note:<br /> In __split_huge_page(), folio_test_anon() &amp;&amp; folio_test_swapcache() is<br /> used to get swap_cache address space, but that ignores the shmem folio in<br /> swap cache case. It could lead to NULL pointer dereferencing when a<br /> in-swap-cache shmem folio is split at __xa_store(), since<br /> !folio_test_anon() is true and folio-&gt;mapping is NULL. But fortunately,<br /> its caller split_huge_page_to_list_to_order() bails out early with EBUSY<br /> when folio-&gt;mapping is NULL. So no need to take care of it here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state<br /> <br /> There are several problems with the way hyp code lazily saves the host&amp;#39;s<br /> FPSIMD/SVE state, including:<br /> <br /> * Host SVE being discarded unexpectedly due to inconsistent<br /> configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to<br /> result in QEMU crashes where SVE is used by memmove(), as reported by<br /> Eric Auger:<br /> <br /> https://issues.redhat.com/browse/RHEL-68997<br /> <br /> * Host SVE state is discarded *after* modification by ptrace, which was an<br /> unintentional ptrace ABI change introduced with lazy discarding of SVE state.<br /> <br /> * The host FPMR value can be discarded when running a non-protected VM,<br /> where FPMR support is not exposed to a VM, and that VM uses<br /> FPSIMD/SVE. In these cases the hyp code does not save the host&amp;#39;s FPMR<br /> before unbinding the host&amp;#39;s FPSIMD/SVE/SME state, leaving a stale<br /> value in memory.<br /> <br /> Avoid these by eagerly saving and "flushing" the host&amp;#39;s FPSIMD/SVE/SME<br /> state when loading a vCPU such that KVM does not need to save any of the<br /> host&amp;#39;s FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is<br /> removed and the necessary call to fpsimd_save_and_flush_cpu_state() is<br /> placed in kvm_arch_vcpu_load_fp(). As &amp;#39;fpsimd_state&amp;#39; and &amp;#39;fpmr_ptr&amp;#39;<br /> should not be used, they are set to NULL; all uses of these will be<br /> removed in subsequent patches.<br /> <br /> Historical problems go back at least as far as v5.17, e.g. erroneous<br /> assumptions about TIF_SVE being clear in commit:<br /> <br /> 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving")<br /> <br /> ... and so this eager save+flush probably needs to be backported to ALL<br /> stable trees.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: dts: bcm2711: Fix xHCI power-domain<br /> <br /> During s2idle tests on the Raspberry CM4 the VPU firmware always crashes<br /> on xHCI power-domain resume:<br /> <br /> root@raspberrypi:/sys/power# echo freeze &gt; state<br /> [ 70.724347] xhci_suspend finished<br /> [ 70.727730] xhci_plat_suspend finished<br /> [ 70.755624] bcm2835-power bcm2835-power: Power grafx off<br /> [ 70.761127] USB: Set power to 0<br /> <br /> [ 74.653040] USB: Failed to set power to 1 (-110)<br /> <br /> This seems to be caused because of the mixed usage of<br /> raspberrypi-power and bcm2835-power at the same time. So avoid<br /> the usage of the VPU firmware power-domain driver, which<br /> prevents the VPU crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"<br /> <br /> There are reports that the pagetable walker cache coherency is not a<br /> given across the spectrum of SDM845/850 devices, leading to lock-ups<br /> and resets. It works fine on some devices (like the Dragonboard 845c,<br /> but not so much on the Lenovo Yoga C630).<br /> <br /> This unfortunately looks like a fluke in firmware development, where<br /> likely somewhere in the vast hypervisor stack, a change to accommodate<br /> for this was only introduced after the initial software release (which<br /> often serves as a baseline for products).<br /> <br /> Revert the change to avoid additional guesswork around crashes.<br /> <br /> This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pdr: Fix the potential deadlock<br /> <br /> When some client process A call pdr_add_lookup() to add the look up for<br /> the service and does schedule locator work, later a process B got a new<br /> server packet indicating locator is up and call pdr_locator_new_server()<br /> which eventually sets pdr-&gt;locator_init_complete to true which process A<br /> sees and takes list lock and queries domain list but it will timeout due<br /> to deadlock as the response will queued to the same qmi-&gt;wq and it is<br /> ordered workqueue and process B is not able to complete new server<br /> request work due to deadlock on list lock.<br /> <br /> Fix it by removing the unnecessary list iteration as the list iteration<br /> is already being done inside locator work, so avoid it here and just<br /> call schedule_work() here.<br /> <br /> Process A Process B<br /> <br /> process_scheduled_works()<br /> pdr_add_lookup() qmi_data_ready_work()<br /> process_scheduled_works() pdr_locator_new_server()<br /> pdr-&gt;locator_init_complete=true;<br /> pdr_locator_work()<br /> mutex_lock(&amp;pdr-&gt;list_lock);<br /> <br /> pdr_locate_service() mutex_lock(&amp;pdr-&gt;list_lock);<br /> <br /> pdr_get_domain_list()<br /> pr_err("PDR: %s get domain list<br /> txn wait failed: %d\n",<br /> req-&gt;service_name,<br /> ret);<br /> <br /> Timeout error log due to deadlock:<br /> <br /> "<br /> PDR: tms/servreg get domain list txn wait failed: -110<br /> PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110<br /> "<br /> <br /> Thanks to Bjorn and Johan for letting me know that this commit also fixes<br /> an audio regression when using the in-kernel pd-mapper as that makes it<br /> easier to hit this race. [1]