Vulnerabilities

Missing Authorization vulnerability in Essekia Tablesome tablesome allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Tablesome: from n/a through

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Steve Truman Email Inquiry & Cart Options for WooCommerce woocommerce-email-inquiry-cart-options allows DOM-Based XSS.This issue affects Email Inquiry & Cart Options for WooCommerce: from n/a through

Missing Authorization vulnerability in sheepfish WebP Conversion webp-conversion allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WebP Conversion: from n/a through

Missing Authorization vulnerability in Alejandro Quick Restaurant Reservations quick-restaurant-reservations allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Quick Restaurant Reservations: from n/a through

Missing Authorization vulnerability in CloudPanel CLP Varnish Cache clp-varnish-cache allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CLP Varnish Cache: from n/a through

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in pixelgrade Nova Blocks nova-blocks allows DOM-Based XSS.This issue affects Nova Blocks: from n/a through

Missing Authorization vulnerability in MyThemeShop WP Subscribe wp-subscribe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Subscribe: from n/a through

Cross-Site Request Forgery (CSRF) vulnerability in Timur Kamaev Kama Thumbnail kama-thumbnail allows Cross Site Request Forgery.This issue affects Kama Thumbnail: from n/a through

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: properly keep track of conduit reference<br /> <br /> Problem description<br /> -------------------<br /> <br /> DSA has a mumbo-jumbo of reference handling of the conduit net device<br /> and its kobject which, sadly, is just wrong and doesn&amp;#39;t make sense.<br /> <br /> There are two distinct problems.<br /> <br /> 1. The OF path, which uses of_find_net_device_by_node(), never releases<br /> the elevated refcount on the conduit&amp;#39;s kobject. Nominally, the OF and<br /> non-OF paths should result in objects having identical reference<br /> counts taken, and it is already suspicious that<br /> dsa_dev_to_net_device() has a put_device() call which is missing in<br /> dsa_port_parse_of(), but we can actually even verify that an issue<br /> exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command<br /> "before" and "after" applying this patch:<br /> <br /> (unbind the conduit driver for net device eno2)<br /> echo 0000:00:00.2 &gt; /sys/bus/pci/drivers/fsl_enetc/unbind<br /> <br /> we see these lines in the output diff which appear only with the patch<br /> applied:<br /> <br /> kobject: &amp;#39;eno2&amp;#39; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)<br /> kobject: &amp;#39;109&amp;#39; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)<br /> <br /> 2. After we find the conduit interface one way (OF) or another (non-OF),<br /> it can get unregistered at any time, and DSA remains with a long-lived,<br /> but in this case stale, cpu_dp-&gt;conduit pointer. Holding the net<br /> device&amp;#39;s underlying kobject isn&amp;#39;t actually of much help, it just<br /> prevents it from being freed (but we never need that kobject<br /> directly). What helps us to prevent the net device from being<br /> unregistered is the parallel netdev reference mechanism (dev_hold()<br /> and dev_put()).<br /> <br /> Actually we actually use that netdev tracker mechanism implicitly on<br /> user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with<br /> the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().<br /> But time still passes at DSA switch probe time between the initial<br /> of_find_net_device_by_node() code and the user port creation time, time<br /> during which the conduit could unregister itself and DSA wouldn&amp;#39;t know<br /> about it.<br /> <br /> So we have to run of_find_net_device_by_node() under rtnl_lock() to<br /> prevent that from happening, and release the lock only with the netdev<br /> tracker having acquired the reference.<br /> <br /> Do we need to keep the reference until dsa_unregister_switch() /<br /> dsa_switch_shutdown()?<br /> 1: Maybe yes. A switch device will still be registered even if all user<br /> ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not<br /> make user port errors fatal"), and the cpu_dp-&gt;conduit pointers<br /> remain valid. I haven&amp;#39;t audited all call paths to see whether they<br /> will actually use the conduit in lack of any user port, but if they<br /> do, it seems safer to not rely on user ports for that reference.<br /> 2. Definitely yes. We support changing the conduit which a user port is<br /> associated to, and we can get into a situation where we&amp;#39;ve moved all<br /> user ports away from a conduit, thus no longer hold any reference to<br /> it via the net device tracker. But we shouldn&amp;#39;t let it go nonetheless<br /> - see the next change in relation to dsa_tree_find_first_conduit()<br /> and LAG conduits which disappear.<br /> We have to be prepared to return to the physical conduit, so the CPU<br /> port must explicitly keep another reference to it. This is also to<br /> say: the user ports and their CPU ports may not always keep a<br /> reference to the same conduit net device, and both are needed.<br /> <br /> As for the conduit&amp;#39;s kobject for the /sys/class/net/ entry, we don&amp;#39;t<br /> care about it, we can release it as soon as we hold the net device<br /> object itself.<br /> <br /> History and blame attribution<br /> -----------------------------<br /> <br /> The code has been refactored so many times, it is very difficult to<br /> follow and properly attribute a blame, but I&amp;#39;ll try to make a short<br /> history which I hope to be correct.<br /> <br /> We have two distinct probing paths:<br /> - one for OF, introduced in 2016 i<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix memory leak in get_file_all_info()<br /> <br /> In get_file_all_info(), if vfs_getattr() fails, the function returns<br /> immediately without freeing the allocated filename, leading to a memory<br /> leak.<br /> <br /> Fix this by freeing the filename before returning in this error case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: rtl8150: fix memory leak on usb_submit_urb() failure<br /> <br /> In async_set_registers(), when usb_submit_urb() fails, the allocated<br /> async_req structure and URB are not freed, causing a memory leak.<br /> <br /> The completion callback async_set_reg_cb() is responsible for freeing<br /> these allocations, but it is only called after the URB is successfully<br /> submitted and completes (successfully or with error). If submission<br /> fails, the callback never runs and the memory is leaked.<br /> <br /> Fix this by freeing both the URB and the request structure in the error<br /> path when usb_submit_urb() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: Fix gmap_helper_zap_one_page() again<br /> <br /> A few checks were missing in gmap_helper_zap_one_page(), which can lead<br /> to memory corruption in the guest under specific circumstances.<br /> <br /> Add the missing checks.