Vulnerabilities

The LA-Studio Element Kit for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's Table of Contents widget in all versions up to, and including, 1.4.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.

The Download Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 3.3.12 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 the SVG file.

A vulnerability has been found in D-Link DWR-M961 1.1.36 and classified as critical. This vulnerability affects unknown code of the file /boafrm/formStaticDHCP of the component Authorization Interface. The manipulation of the argument Hostname leads to stack-based buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.49 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability was found in Tenda AC15 up to 15.03.05.19 and classified as critical. This issue affects the function fromSetWirelessRepeat of the file /goform/WifiExtraSet. The manipulation of the argument mac leads to buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

An improper authentication control vulnerability exists in AiCloud. This vulnerability can be triggered by a crafted request, potentially leading to unauthorized execution of functions.<br /> <br /> <br /> Refer to the &amp;#39;ASUS Router AiCloud vulnerability&amp;#39; section on the ASUS Security Advisory for more information.

Rejected reason: Not used

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()<br /> <br /> If speed_hz

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gpib: Fix cb7210 pcmcia Oops<br /> <br /> The pcmcia_driver struct was still only using the old .name<br /> initialization in the drv field. This led to a NULL pointer<br /> deref Oops in strcmp called from pcmcia_register_driver.<br /> <br /> Initialize the pcmcia_driver struct name field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show()<br /> <br /> The csts_state_names[] array only has six sparse entries, but the<br /> iteration code in nvmet_ctrl_state_show() iterates seven, resulting in a<br /> potential out-of-bounds stack read. Fix that.<br /> <br /> Fixes the following warning with an UBSAN kernel:<br /> <br /> vmlinux.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: Add check for array bounds in veml6075_read_int_time_ms<br /> <br /> The array contains only 5 elements, but the index calculated by<br /> veml6075_read_int_time_index can range from 0 to 7,<br /> which could lead to out-of-bounds access. The check prevents this issue.<br /> <br /> Coverity Issue<br /> CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN)<br /> overrun-local: Overrunning array veml6075_it_ms of 5 4-byte<br /> elements at element index 7 (byte offset 31) using<br /> index int_index (which evaluates to 7)<br /> <br /> This is hardening against potentially broken hardware. Good to have<br /> but not necessary to backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mce: use is_copy_from_user() to determine copy-from-user context<br /> <br /> Patch series "mm/hwpoison: Fix regressions in memory failure handling",<br /> v4.<br /> <br /> ## 1. What am I trying to do:<br /> <br /> This patchset resolves two critical regressions related to memory failure<br /> handling that have appeared in the upstream kernel since version 5.17, as<br /> compared to 5.10 LTS.<br /> <br /> - copyin case: poison found in user page while kernel copying from user space<br /> - instr case: poison found while instruction fetching in user space<br /> <br /> ## 2. What is the expected outcome and why<br /> <br /> - For copyin case:<br /> <br /> Kernel can recover from poison found where kernel is doing get_user() or<br /> copy_from_user() if those places get an error return and the kernel return<br /> -EFAULT to the process instead of crashing. More specifily, MCE handler<br /> checks the fixup handler type to decide whether an in kernel #MC can be<br /> recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code<br /> specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.<br /> <br /> - For instr case:<br /> <br /> If a poison found while instruction fetching in user space, full recovery<br /> is possible. User process takes #PF, Linux allocates a new page and fills<br /> by reading from storage.<br /> <br /> <br /> ## 3. What actually happens and why<br /> <br /> - For copyin case: kernel panic since v5.17<br /> <br /> Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new<br /> extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the<br /> extable fixup type for copy-from-user operations, changing it from<br /> EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS<br /> handling when posion found in get_user() or copy_from_user().<br /> <br /> - For instr case: user process is killed by a SIGBUS signal due to #CMCI<br /> and #MCE race<br /> <br /> When an uncorrected memory error is consumed there is a race between the<br /> CMCI from the memory controller reporting an uncorrected error with a UCNA<br /> signature, and the core reporting and SRAR signature machine check when<br /> the data is about to be consumed.<br /> <br /> ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]<br /> <br /> Prior to Icelake memory controllers reported patrol scrub events that<br /> detected a previously unseen uncorrected error in memory by signaling a<br /> broadcast machine check with an SRAO (Software Recoverable Action<br /> Optional) signature in the machine check bank. This was overkill because<br /> it&amp;#39;s not an urgent problem that no core is on the verge of consuming that<br /> bad data. It&amp;#39;s also found that multi SRAO UCE may cause nested MCE<br /> interrupts and finally become an IERR.<br /> <br /> Hence, Intel downgrades the machine check bank signature of patrol scrub<br /> from SRAO to UCNA (Uncorrected, No Action required), and signal changed to<br /> #CMCI. Just to add to the confusion, Linux does take an action (in<br /> uc_decode_notifier()) to try to offline the page despite the UC*NA*<br /> signature name.<br /> <br /> ### Background: why #CMCI and #MCE race when poison is consuming in<br /> Intel platform [1]<br /> <br /> Having decided that CMCI/UCNA is the best action for patrol scrub errors,<br /> the memory controller uses it for reads too. But the memory controller is<br /> executing asynchronously from the core, and can&amp;#39;t tell the difference<br /> between a "real" read and a speculative read. So it will do CMCI/UCNA if<br /> an error is found in any read.<br /> <br /> Thus:<br /> <br /> 1) Core is clever and thinks address A is needed soon, issues a<br /> speculative read.<br /> <br /> 2) Core finds it is going to use address A soon after sending the read<br /> request<br /> <br /> 3) The CMCI from the memory controller is in a race with MCE from the<br /> core that will soon try to retire the load from address A.<br /> <br /> Quite often (because speculation has got better) the CMCI from the memory<br /> controller is delivered before the core is committed to the instruction<br /> reading address A, so the interrupt is taken, and Linux offlines the page<br /> (marking it as poison).<br /> <br /> <br /> ## Why user process is killed for instr case<br /> <br /> Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported<br /> "not<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: simple-card-utils: Don&amp;#39;t use __free(device_node) at graph_util_parse_dai()<br /> <br /> commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for<br /> device node") uses __free(device_node) for dlc-&gt;of_node, but we need to<br /> keep it while driver is in use.<br /> <br /> Don&amp;#39;t use __free(device_node) in graph_util_parse_dai().