Vulnerabilities

The Flamix: Bitrix24 and Contact Form 7 integrations plugin for WordPress is vulnerable to Full Path Disclosure in all versions up to, and including, 3.1.0. This is due the plugin utilizing mobiledetect without preventing direct access to the files. This makes it possible for unauthenticated attackers to retrieve the full path of the web application, which can be used to aid other attacks. The information displayed is not useful on its own, and requires another vulnerability to be present for damage to an affected website.

The WordSurvey plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘sounding_title’ parameter in all versions up to, and including, 3.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level access, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

The Hide My Site plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.2 due to the plugin not restricting access to the REST API when password protection is enabled. This makes it possible for unauthenticated attackers to gain unauthorized access to the site.

A cross-site scripting (XSS) vulnerability in the component /index/index.html of YZNCMS v1.4.2 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the configured remarks text field.

Dell SupportAssist for Home PCs Installer exe version 4.0.3 contains a privilege escalation vulnerability in the installer. A local low-privileged authenticated attacker could potentially exploit this vulnerability, leading to the execution of arbitrary executables on the operating system with elevated privileges.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: ivtv: Add check for DMA map result<br /> <br /> In case DMA fails, &amp;#39;dma-&gt;SG_length&amp;#39; is 0. This value is later used to<br /> access &amp;#39;dma-&gt;SGarray[dma-&gt;SG_length - 1]&amp;#39;, which will cause out of<br /> bounds access.<br /> <br /> Add check to return early on invalid value. Adjust warnings accordingly.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Fix input error path memory access<br /> <br /> When there is a misconfiguration of input state slow path<br /> KASAN report error. Fix this error.<br /> west login:<br /> [ 52.987278] eth1: renamed from veth11<br /> [ 53.078814] eth1: renamed from veth21<br /> [ 53.181355] eth1: renamed from veth31<br /> [ 54.921702] ==================================================================<br /> [ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512<br /> [ 54.924169]<br /> [ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25<br /> [ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 54.926401] Call Trace:<br /> [ 54.926731] <br /> [ 54.927009] dump_stack_lvl+0x2a/0x3b<br /> [ 54.927478] kasan_report+0x84/0xa6<br /> [ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.928410] xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e<br /> [ 54.929354] xfrm4_rcv_cb+0x46/0x5e<br /> [ 54.929804] xfrm_rcv_cb+0x7e/0xa1<br /> [ 54.930240] xfrm_input+0x1b3a/0x1b96<br /> [ 54.930715] ? xfrm_offload+0x41/0x41<br /> [ 54.931182] ? raw_rcv+0x292/0x292<br /> [ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2<br /> [ 54.932158] ? skb_sec_path+0xd/0x3f<br /> [ 54.932610] ? xfrmi_input+0x90/0xce<br /> [ 54.933066] xfrm4_esp_rcv+0x33/0x54<br /> [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2<br /> [ 54.934089] ip_local_deliver_finish+0x110/0x120<br /> [ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2<br /> [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138<br /> [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68<br /> [ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168<br /> [ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2<br /> [ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d<br /> [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138<br /> [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68<br /> [ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d<br /> [ 54.939904] ? ip_local_deliver_finish+0x120/0x120<br /> [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107<br /> [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2<br /> [ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9<br /> [ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38<br /> [ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b<br /> [ 54.943618] process_backlog+0xb3/0x187<br /> [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7<br /> [ 54.944669] net_rx_action+0x1cb/0x380<br /> [ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7<br /> [ 54.945744] ? vring_new_virtqueue+0x17a/0x17a<br /> [ 54.946300] ? note_interrupt+0x2cd/0x367<br /> [ 54.946805] handle_softirqs+0x13c/0x2c9<br /> [ 54.947300] do_softirq+0x5f/0x7d<br /> [ 54.947727] <br /> [ 54.948014] <br /> [ 54.948300] __local_bh_enable_ip+0x48/0x62<br /> [ 54.948832] __neigh_event_send+0x3fd/0x4ca<br /> [ 54.949361] neigh_resolve_output+0x1e/0x210<br /> [ 54.949896] ip_finish_output2+0x4bf/0x4f0<br /> [ 54.950410] ? __ip_finish_output+0x171/0x1b8<br /> [ 54.950956] ip_send_skb+0x25/0x57<br /> [ 54.951390] raw_sendmsg+0xf95/0x10c0<br /> [ 54.951850] ? check_new_pages+0x45/0x71<br /> [ 54.952343] ? raw_hash_sk+0x21b/0x21b<br /> [ 54.952815] ? kernel_init_pages+0x42/0x51<br /> [ 54.953337] ? prep_new_page+0x44/0x51<br /> [ 54.953811] ? get_page_from_freelist+0x72b/0x915<br /> [ 54.954390] ? signal_pending_state+0x77/0x77<br /> [ 54.954936] ? preempt_count_sub+0x14/0xb3<br /> [ 54.955450] ? __might_resched+0x8a/0x240<br /> [ 54.955951] ? __might_sleep+0x25/0xa0<br /> [ 54.956424] ? first_zones_zonelist+0x2c/0x43<br /> [ 54.956977] ? __rcu_read_lock+0x2d/0x3a<br /> [ 54.957476] ? __pte_offset_map+0x32/0xa4<br /> [ 54.957980] ? __might_resched+0x8a/0x240<br /> [ 54.958483] ? __might_sleep+0x25/0xa0<br /> [ 54.958963] ? inet_send_prepare+0x54/0x54<br /> [ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c<br /> [ 54.960000] sock_sendmsg_nosec+0x42/0x6c<br /> [ 54.960502] __sys_sendto+0x15d/0x1cc<br /> [ 54.960966] ? __x64_sys_getpeername+0x44/0x44<br /> [ 54.961522] ? __handle_mm_fault+0x679/0xae4<br /> [ 54.962068] ? find_vma+0x6b/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()<br /> <br /> Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in<br /> cfg80211_calculate_bitrate_he(), leading to below warning:<br /> <br /> kernel: invalid HE MCS: bw:6, ru:6<br /> kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]<br /> <br /> Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_erp: Fix object nesting warning<br /> <br /> ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM<br /> (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can<br /> contain more ACLs (i.e., tc filters), but the number of masks in each<br /> region (i.e., tc chain) is limited.<br /> <br /> In order to mitigate the effects of the above limitation, the device<br /> allows filters to share a single mask if their masks only differ in up<br /> to 8 consecutive bits. For example, dst_ip/25 can be represented using<br /> dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the<br /> number of masks being used (and therefore does not support mask<br /> aggregation), but can contain a limited number of filters.<br /> <br /> The driver uses the "objagg" library to perform the mask aggregation by<br /> passing it objects that consist of the filter&amp;#39;s mask and whether the<br /> filter is to be inserted into the A-TCAM or the C-TCAM since filters in<br /> different TCAMs cannot share a mask.<br /> <br /> The set of created objects is dependent on the insertion order of the<br /> filters and is not necessarily optimal. Therefore, the driver will<br /> periodically ask the library to compute a more optimal set ("hints") by<br /> looking at all the existing objects.<br /> <br /> When the library asks the driver whether two objects can be aggregated<br /> the driver only compares the provided masks and ignores the A-TCAM /<br /> C-TCAM indication. This is the right thing to do since the goal is to<br /> move as many filters as possible to the A-TCAM. The driver also forbids<br /> two identical masks from being aggregated since this can only happen if<br /> one was intentionally put in the C-TCAM to avoid a conflict in the<br /> A-TCAM.<br /> <br /> The above can result in the following set of hints:<br /> <br /> H1: {mask X, A-TCAM} -&gt; H2: {mask Y, A-TCAM} // X is Y + delta<br /> H3: {mask Y, C-TCAM} -&gt; H4: {mask Z, A-TCAM} // Y is Z + delta<br /> <br /> After getting the hints from the library the driver will start migrating<br /> filters from one region to another while consulting the computed hints<br /> and instructing the device to perform a lookup in both regions during<br /> the transition.<br /> <br /> Assuming a filter with mask X is being migrated into the A-TCAM in the<br /> new region, the hints lookup will return H1. Since H2 is the parent of<br /> H1, the library will try to find the object associated with it and<br /> create it if necessary in which case another hints lookup (recursive)<br /> will be performed. This hints lookup for {mask Y, A-TCAM} will either<br /> return H2 or H3 since the driver passes the library an object comparison<br /> function that ignores the A-TCAM / C-TCAM indication.<br /> <br /> This can eventually lead to nested objects which are not supported by<br /> the library [1].<br /> <br /> Fix by removing the object comparison function from both the driver and<br /> the library as the driver was the only user. That way the lookup will<br /> only return exact matches.<br /> <br /> I do not have a reliable reproducer that can reproduce the issue in a<br /> timely manner, but before the fix the issue would reproduce in several<br /> minutes and with the fix it does not reproduce in over an hour.<br /> <br /> Note that the current usefulness of the hints is limited because they<br /> include the C-TCAM indication and represent aggregation that cannot<br /> actually happen. This will be addressed in net-next.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0<br /> Modules linked in:<br /> CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42<br /> Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0<br /> [...]<br /> Call Trace:<br /> <br /> __objagg_obj_get+0x2bb/0x580<br /> objagg_obj_get+0xe/0x80<br /> mlxsw_sp_acl_erp_mask_get+0xb5/0xf0<br /> mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0<br /> mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510<br /> process_one_work+0x151/0x370

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: change DMA direction while mapping reinjected packets<br /> <br /> For fragmented packets, ath12k reassembles each fragment as a normal<br /> packet and then reinjects it into HW ring. In this case, the DMA<br /> direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,<br /> an invalid payload may be reinjected into the HW and<br /> subsequently delivered to the host.<br /> <br /> Given that arbitrary memory can be allocated to the skb buffer,<br /> knowledge about the data contained in the reinjected buffer is lacking.<br /> Consequently, there’s a risk of private information being leaked.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: Fix ToCToU between perm check and set-uid/gid usage<br /> <br /> When opening a file for exec via do_filp_open(), permission checking is<br /> done against the file&amp;#39;s metadata at that moment, and on success, a file<br /> pointer is passed back. Much later in the execve() code path, the file<br /> metadata (specifically mode, uid, and gid) is used to determine if/how<br /> to set the uid and gid. However, those values may have changed since the<br /> permissions check, meaning the execution may gain unintended privileges.<br /> <br /> For example, if a file could change permissions from executable and not<br /> set-id:<br /> <br /> ---------x 1 root root 16048 Aug 7 13:16 target<br /> <br /> to set-id and non-executable:<br /> <br /> ---S------ 1 root root 16048 Aug 7 13:16 target<br /> <br /> it is possible to gain root privileges when execution should have been<br /> disallowed.<br /> <br /> While this race condition is rare in real-world scenarios, it has been<br /> observed (and proven exploitable) when package managers are updating<br /> the setuid bits of installed programs. Such files start with being<br /> world-executable but then are adjusted to be group-exec with a set-uid<br /> bit. For example, "chmod o-x,u+s target" makes "target" executable only<br /> by uid "root" and gid "cdrom", while also becoming setuid-root:<br /> <br /> -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> becomes:<br /> <br /> -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> But racing the chmod means users without group "cdrom" membership can<br /> get the permission to execute "target" just before the chmod, and when<br /> the chmod finishes, the exec reaches brpm_fill_uid(), and performs the<br /> setuid to root, violating the expressed authorization of "only cdrom<br /> group members can setuid to root".<br /> <br /> Re-check that we still have execute permissions in case the metadata<br /> has changed. It would be better to keep a copy from the perm-check time,<br /> but until we can do that refactoring, the least-bad option is to do a<br /> full inode_permission() call (under inode lock). It is understood that<br /> this is safe against dead-locks, but hardly optimal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exec and file release<br /> <br /> The perf pending task work is never waited upon the matching event<br /> release. In the case of a child event, released via free_event()<br /> directly, this can potentially result in a leaked event, such as in the<br /> following scenario that doesn&amp;#39;t even require a weak IRQ work<br /> implementation to trigger:<br /> <br /> schedule()<br /> prepare_task_switch()<br /> =======&gt; <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = ...<br /> irq_work_queue(&amp;event-&gt;pending_irq)<br /> pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> task_work_add(&amp;event-&gt;pending_task)<br /> finish_lock_switch()<br /> =======&gt; <br /> perf_pending_irq()<br /> //do nothing, rely on pending task work<br /> refcount, 1, 0) != 1)<br /> // event is leaked<br /> <br /> Similar scenarios can also happen with perf_event_remove_on_exec() or<br /> simply against concurrent perf_event_release().<br /> <br /> Fix this with synchonizing against the possibly remaining pending task<br /> work while freeing the event, just like is done with remaining pending<br /> IRQ work. This means that the pending task callback neither need nor<br /> should hold a reference to the event, preventing it from ever beeing<br /> freed.