Security Vulnerabilities
- CVEs Published In January 2025
A vulnerability was found in StarSea99 starsea-mall 1.0. It has been declared as critical. This vulnerability affects the function UploadController of the file src/main/java/com/siro/mall/controller/common/uploadController.java. The manipulation of the argument file leads to unrestricted upload. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
A vulnerability was found in StarSea99 starsea-mall 1.0. It has been rated as problematic. This issue affects some unknown processing of the file /admin/categories/update. The manipulation of the argument categoryName leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.
HCL MyXalytics is affected by a cleartext transmission of sensitive information vulnerability. The application transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
HCL MyXalytics is affected by a malicious file upload vulnerability. The application accepts invalid file uploads, including incorrect content types, double extensions, null bytes, and special characters, allowing attackers to upload and execute malicious files.
HCL MyXalytics is affected by sensitive information disclosure vulnerability. The HTTP response header exposes the Microsoft-HTTP API∕2.0 as the server's name & version.
IBM Robotic Process Automation 21.0.0 through 21.0.7.19 and 23.0.0 through 23.0.19 could allow a remote attacker to obtain sensitive data that may be exposed through certain crypto-analytic attacks.
IBM Jazz Foundation 6.0.6, 6.0.6.1, 7.0, 7.0.1, and 7.0.2 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
IBM watsonx.ai 1.1 through 2.0.3 and IBM watsonx.ai on Cloud Pak for Data 4.8 through 5.0.3 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()
In split_large_buddy(), we might call pfn_to_page() on a PFN that might
not exist. In corner cases, such as when freeing the highest pageblock in
the last memory section, this could result with CONFIG_SPARSEMEM &&
!CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and
__section_mem_map_addr() dereferencing that NULL pointer.
Let's fix it, and avoid doing a pfn_to_page() call for the first
iteration, where we already have the page.
So far this was found by code inspection, but let's just CC stable as the
fix is easy.
In the Linux kernel, the following vulnerability has been resolved:
arm64: ptrace: fix partial SETREGSET for NT_ARM_POE
Currently poe_set() doesn't initialize the temporary 'ctrl' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.por_el0, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.
Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of POR_EL1 will be retained.
Before this patch:
| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0xffff8000839c3d50
After this patch:
| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d