Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix vlan tunnel dst null pointer dereference<br /> <br /> This patch fixes a tunnel_dst null pointer dereference due to lockless<br /> access in the tunnel egress path. When deleting a vlan tunnel the<br /> tunnel_dst pointer is set to NULL without waiting a grace period (i.e.<br /> while it&amp;#39;s still usable) and packets egressing are dereferencing it<br /> without checking. Use READ/WRITE_ONCE to annotate the lockless use of<br /> tunnel_id, use RCU for accessing tunnel_dst and make sure it is read<br /> only once and checked in the egress path. The dst is already properly RCU<br /> protected so we don&amp;#39;t need to do anything fancy than to make sure<br /> tunnel_id and tunnel_dst are read only once and checked in the egress path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ll_temac: Make sure to free skb when it is completely used<br /> <br /> With the skb pointer piggy-backed on the TX BD, we have a simple and<br /> efficient way to free the skb buffer when the frame has been transmitted.<br /> But in order to avoid freeing the skb while there are still fragments from<br /> the skb in use, we need to piggy-back on the TX BD of the skb, not the<br /> first.<br /> <br /> Without this, we are doing use-after-free on the DMA side, when the first<br /> BD of a multi TX BD packet is seen as completed in xmit_done, and the<br /> remaining BDs are still being processed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix deadlock in AP/VLAN handling<br /> <br /> Syzbot reports that when you have AP_VLAN interfaces that are up<br /> and close the AP interface they belong to, we get a deadlock. No<br /> surprise - since we dev_close() them with the wiphy mutex held,<br /> which goes back into the netdev notifier in cfg80211 and tries to<br /> acquire the wiphy mutex there.<br /> <br /> To fix this, we need to do two things:<br /> 1) prevent changing iftype while AP_VLANs are up, we can&amp;#39;t<br /> easily fix this case since cfg80211 already calls us with<br /> the wiphy mutex held, but change_interface() is relatively<br /> rare in drivers anyway, so changing iftype isn&amp;#39;t used much<br /> (and userspace has to fall back to down/change/up anyway)<br /> 2) pull the dev_close() loop over VLANs out of the wiphy mutex<br /> section in the normal stop case

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer<br /> <br /> Both Intel and AMD consider it to be architecturally valid for XRSTOR to<br /> fail with #PF but nonetheless change the register state. The actual<br /> conditions under which this might occur are unclear [1], but it seems<br /> plausible that this might be triggered if one sibling thread unmaps a page<br /> and invalidates the shared TLB while another sibling thread is executing<br /> XRSTOR on the page in question.<br /> <br /> __fpu__restore_sig() can execute XRSTOR while the hardware registers<br /> are preserved on behalf of a different victim task (using the<br /> fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but<br /> modify the registers.<br /> <br /> If this happens, then there is a window in which __fpu__restore_sig()<br /> could schedule out and the victim task could schedule back in without<br /> reloading its own FPU registers. This would result in part of the FPU<br /> state that __fpu__restore_sig() was attempting to load leaking into the<br /> victim task&amp;#39;s user-visible state.<br /> <br /> Invalidate preserved FPU registers on XRSTOR failure to prevent this<br /> situation from corrupting any state.<br /> <br /> [1] Frequent readers of the errata lists might imagine "complex<br /> microarchitectural conditions".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Prevent state corruption in __fpu__restore_sig()<br /> <br /> The non-compacted slowpath uses __copy_from_user() and copies the entire<br /> user buffer into the kernel buffer, verbatim. This means that the kernel<br /> buffer may now contain entirely invalid state on which XRSTOR will #GP.<br /> validate_user_xstate_header() can detect some of that corruption, but that<br /> leaves the onus on callers to clear the buffer.<br /> <br /> Prior to XSAVES support, it was possible just to reinitialize the buffer,<br /> completely, but with supervisor states that is not longer possible as the<br /> buffer clearing code split got it backwards. Fixing that is possible but<br /> not corrupting the state in the first place is more robust.<br /> <br /> Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()<br /> which validates the XSAVE header contents before copying the actual states<br /> to the kernel. copy_user_to_xstate() was previously only called for<br /> compacted-format kernel buffers, but it works for both compacted and<br /> non-compacted forms.<br /> <br /> Using it for the non-compacted form is slower because of multiple<br /> __copy_from_user() operations, but that cost is less important than robust<br /> code in an already slow path.<br /> <br /> [ Changelog polished by Dave Hansen ]

Umbraco CMS is an ASP.NET CMS used by more than 730.000 websites. Stored Cross-site scripting (XSS) enable attackers that have access to backoffice to bring malicious content into a website or application. This vulnerability has been patched in version(s) 8.18.13, 10.8.4, 12.3.7, 13.1.1 by implementing IHtmlSanitizer.<br /> <br /> <br /> <br /> <br />

An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_array_length function in the mjs.c file.

An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_mk_ffi_sig function in the mjs.c file.

An issue in Cesanta mjs 2.20.0 allows a remote attacker to cause a denial of service via the mjs_do_gc function in the mjs.c file.

The ElementsKit Pro plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in versions up to, and including, 3.6.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Stack-based Buffer Overflow vulnerability in ZkTeco-based OEM devices allows, in some cases, the execution of arbitrary code. Due to the lack of protection mechanisms such as stack canaries and PIE, it is possible to successfully execute code even under restrictive conditions.<br /> <br /> This issue affects <br /> ZkTeco-based OEM devices (ZkTeco ProFace X, Smartec ST-FR043, Smartec ST-FR041ME and possibly others)<br /> <br /> with firmware <br /> ZAM170-NF-1.8.25-7354-Ver1.0.0 and possibly others.

Umbraco is an ASP.NET CMS used by more than 730.000 websites. Umbraco has an endpoint that is vulnerable to open redirects. The endpoint is protected so it requires the user to be signed into backoffice before the vulnerable is exposed. This vulnerability has been patched in version(s) 8.18.14, 10.8.6, 12.3.10 and 13.3.1.