Vulnerabilities

A Stored Cross-Site Scripting (XSS) vulnerability has been identified in OpenText ArcSight Enterprise Security Manager and ArcSight Platform. The vulnerability could be remotely exploited.

taurusxin ncmdump v1.3.2 was discovered to contain a segmentation violation via the NeteaseCrypt::FixMetadata() function at /src/ncmcrypt.cpp. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted .ncm file.

A Stored Cross-Site Scripting (XSS) vulnerability has been identified in OpenText ArcSight Enterprise Security Manager and ArcSight Platform. The vulnerability could be remotely exploited.

An issue in taurusxin ncmdump v1.3.2 allows attackers to cause a Denial of Service (DoS) via memory exhaustion by supplying a crafted .ncm file

Zoho ManageEngine ADAudit Plus versions below 7271 allows SQL Injection while getting aggregate report data.

Zohocorp ManageEngine PAM360 version 6601 is vulnerable to authorization vulnerability which allows a low-privileged user to perform admin actions. <br /> Note: This vulnerability affects only the PAM360 6600 version. No other versions are applicable to this vulnerability.

In mintplex-labs/anything-llm, a vulnerability exists due to improper input validation in the workspace update process. Specifically, the application fails to validate or format JSON data sent in an HTTP POST request to `/api/workspace/:workspace-slug/update`, allowing it to be executed as part of a database query without restrictions. This flaw enables users with a manager role to craft a request that includes nested write operations, effectively allowing them to create new Administrator accounts.

A memory corruption vulnerability in Fluent Bit versions 2.0.7 thru 3.0.3. This issue lies in the embedded http server’s parsing of trace requests and may result in denial of service conditions, information disclosure, or remote code execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: fix lock ordering potential deadlock in cifs_sync_mid_result<br /> <br /> Coverity spotted that the cifs_sync_mid_result function could deadlock<br /> <br /> "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires<br /> lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"<br /> <br /> Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: missing lock when picking channel<br /> <br /> Coverity spotted a place where we should have been holding the<br /> channel lock when accessing the ses channel index.<br /> <br /> Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix missing hugetlb_lock for resv uncharge<br /> <br /> There is a recent report on UFFDIO_COPY over hugetlb:<br /> <br /> https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/<br /> <br /> 350: lockdep_assert_held(&amp;hugetlb_lock);<br /> <br /> Should be an issue in hugetlb but triggered in an userfault context, where<br /> it goes into the unlikely path where two threads modifying the resv map<br /> together. Mike has a fix in that path for resv uncharge but it looks like<br /> the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()<br /> will update the cgroup pointer, so it requires to be called with the lock<br /> held.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix the pre-flush when appending to a file in writethrough mode<br /> <br /> In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH<br /> or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed<br /> on a buffered file. When setting up for write-through, we flush any<br /> conflicting writes in the region and wait for the write to complete,<br /> failing if there&amp;#39;s a write error to return.<br /> <br /> The issue arises if we&amp;#39;re writing at or above the EOF position because we<br /> skip the flush and - more importantly - the wait. This becomes a problem<br /> if there&amp;#39;s a partial folio at the end of the file that is being written out<br /> and we want to make a write to it too. Both the already-running write and<br /> the write we start both want to clear the writeback mark, but whoever is<br /> second causes a warning looking something like:<br /> <br /> ------------[ cut here ]------------<br /> R=00000012: folio 11 is not under writeback<br /> WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105<br /> ...<br /> CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...<br /> ...<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> ...<br /> RIP: 0010:netfs_writeback_lookup_folio<br /> <br /> Fix this by making the flush-and-wait unconditional. It will do nothing if<br /> there are no folios in the pagecache and will return quickly if there are<br /> no folios in the region specified.<br /> <br /> Further, move the WBC attachment above the flush call as the flush is going<br /> to attach a WBC and detach it again if it is not present - and since we<br /> need one anyway we might as well share it.