Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: ensure that nfsd4_fattr_args.context is zeroed out<br /> <br /> If nfsd4_encode_fattr4 ends up doing a "goto out" before we get to<br /> checking for the security label, then args.context will be set to<br /> uninitialized junk on the stack, which we&amp;#39;ll then try to free.<br /> Initialize it early.

The Avada | Website Builder For WordPress &amp; eCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s fusion_button shortcode in all versions up to, and including, 3.11.9 due to insufficient input sanitization and output escaping on user supplied attributes. 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. NOTE: This vulnerability was partially fixed in 3.11.9. Additional hardening for alternate attack vectors was added to version 3.11.10.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: Mark get_wq_ctx() as atomic call<br /> <br /> Currently get_wq_ctx() is wrongly configured as a standard call. When two<br /> SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to<br /> resume the corresponding sleeping thread. But if get_wq_ctx() is<br /> interrupted, goes to sleep and another SMC call is waiting to be allocated<br /> a waitq context, it leads to a deadlock.<br /> <br /> To avoid this get_wq_ctx() must be an atomic call and can&amp;#39;t be a standard<br /> SMC call. Hence mark get_wq_ctx() as a fast call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pmic_glink: Fix race during initialization<br /> <br /> As pointed out by Stephen Boyd it is possible that during initialization<br /> of the pmic_glink child drivers, the protection-domain notifiers fires,<br /> and the associated work is scheduled, before the client registration<br /> returns and as a result the local "client" pointer has been initialized.<br /> <br /> The outcome of this is a NULL pointer dereference as the "client"<br /> pointer is blindly dereferenced.<br /> <br /> Timeline provided by Stephen:<br /> CPU0 CPU1<br /> ---- ----<br /> ucsi-&gt;client = NULL;<br /> devm_pmic_glink_register_client()<br /> client-&gt;pdr_notify(client-&gt;priv, pg-&gt;client_state)<br /> pmic_glink_ucsi_pdr_notify()<br /> schedule_work(&amp;ucsi-&gt;register_work)<br /> <br /> pmic_glink_ucsi_register()<br /> ucsi_register()<br /> pmic_glink_ucsi_read_version()<br /> pmic_glink_ucsi_read()<br /> pmic_glink_ucsi_read()<br /> pmic_glink_send(ucsi-&gt;client)<br /> <br /> ucsi-&gt;client = client // Too late!<br /> <br /> This code is identical across the altmode, battery manager and usci<br /> child drivers.<br /> <br /> Resolve this by splitting the allocation of the "client" object and the<br /> registration thereof into two operations.<br /> <br /> This only happens if the protection domain registry is populated at the<br /> time of registration, which by the introduction of commit &amp;#39;1ebcde047c54<br /> ("soc: qcom: add pd-mapper implementation")&amp;#39; became much more likely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix potential UAF in nfsd4_cb_getattr_release<br /> <br /> Once we drop the delegation reference, the fields embedded in it are no<br /> longer safe to access. Do that last.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video/aperture: optionally match the device in sysfb_disable()<br /> <br /> In aperture_remove_conflicting_pci_devices(), we currently only<br /> call sysfb_disable() on vga class devices. This leads to the<br /> following problem when the pimary device is not VGA compatible:<br /> <br /> 1. A PCI device with a non-VGA class is the boot display<br /> 2. That device is probed first and it is not a VGA device so<br /> sysfb_disable() is not called, but the device resources<br /> are freed by aperture_detach_platform_device()<br /> 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()<br /> 4. NULL pointer dereference via sysfb_disable() since the resources<br /> have already been freed by aperture_detach_platform_device() when<br /> it was called by the other device.<br /> <br /> Fix this by passing a device pointer to sysfb_disable() and checking<br /> the device to determine if we should execute it or not.<br /> <br /> v2: Fix build when CONFIG_SCREEN_INFO is not set<br /> v3: Move device check into the mutex<br /> Drop primary variable in aperture_remove_conflicting_pci_devices()<br /> Drop __init on pci sysfb_pci_dev_is_enabled()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Disable preemption while updating GPU stats<br /> <br /> We forgot to disable preemption around the write_seqcount_begin/end() pair<br /> while updating GPU stats:<br /> <br /> [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]<br /> <br /> [ ] Call trace:<br /> [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d]<br /> [ ] v3d_bin_job_run+0x23c/0x388 [v3d]<br /> [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]<br /> [ ] process_one_work+0x62c/0xb48<br /> [ ] worker_thread+0x468/0x5b0<br /> [ ] kthread+0x1c4/0x1e0<br /> [ ] ret_from_fork+0x10/0x20<br /> <br /> Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/mes: fix mes ring buffer overflow<br /> <br /> wait memory room until enough before writing mes packets<br /> to avoid ring buffer overflow.<br /> <br /> v2: squash in sched_hw_submission fix<br /> <br /> (cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined<br /> <br /> create_elf_fdpic_tables() does not correctly account the space for the<br /> AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the<br /> commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv") it<br /> resulted in the last entry of the AUX vector being set to zero, but with<br /> that change it results in a kernel BUG.<br /> <br /> Fix that by adding one to the number of AUXV entries (nitems) when<br /> ELF_HWCAP2 is defined.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially fails<br /> <br /> If z_erofs_gbuf_growsize() partially fails on a global buffer due to<br /> memory allocation failure or fault injection (as reported by syzbot [1]),<br /> new pages need to be freed by comparing to the existing pages to avoid<br /> memory leaks.<br /> <br /> However, the old gbuf-&gt;pages[] array may not be large enough, which can<br /> lead to null-ptr-deref or out-of-bound access.<br /> <br /> Fix this by checking against gbuf-&gt;nrpages in advance.<br /> <br /> [1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: cmd-db: Map shared memory as WC, not WB<br /> <br /> Linux does not write into cmd-db region. This region of memory is write<br /> protected by XPU. XPU may sometime falsely detect clean cache eviction<br /> as "write" into the write protected region leading to secure interrupt<br /> which causes an endless loop somewhere in Trust Zone.<br /> <br /> The only reason it is working right now is because Qualcomm Hypervisor<br /> maps the same region as Non-Cacheable memory in Stage 2 translation<br /> tables. The issue manifests if we want to use another hypervisor (like<br /> Xen or KVM), which does not know anything about those specific mappings.<br /> <br /> Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC<br /> removes dependency on correct mappings in Stage 2 tables. This patch<br /> fixes the issue by updating the mapping to MEMREMAP_WC.<br /> <br /> I tested this on SA8155P with Xen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease<br /> <br /> It is not safe to dereference fl-&gt;c.flc_owner without first confirming<br /> fl-&gt;fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict()<br /> tests fl_lmops but largely ignores the result and assumes that flc_owner<br /> is an nfs4_delegation anyway. This is wrong.<br /> <br /> With this patch we restore the "!= &amp;nfsd_lease_mng_ops" case to behave<br /> as it did before the change mentioned below. This is the same as the<br /> current code, but without any reference to a possible delegation.