CVE Database

Missing Authorization vulnerability in Saad Iqbal Post SMTP post-smtp allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Post SMTP: from n/a through <= 2.9.11.

CloudStack users can add and read comments (annotations) on resources they are authorised to access.  Due to an access validation issue that affects Apache CloudStack versions from 4.16.0, users who have access, prior access or knowledge of resource UUIDs can list and add comments (annotations) to such resources.  An attacker with a user-account and access or prior knowledge of resource UUIDs may exploit this issue to read contents of the comments (annotations) or add malicious comments (annotations) to such resources.  This may cause potential loss of confidentiality of CloudStack environments and resources if the comments (annotations) contain any privileged information. However, guessing or brute-forcing resource UUIDs are generally hard to impossible and access to listing or adding comments isn't same as access to CloudStack resources, making this issue of very low severity and general low impact. CloudStack admins may also disallow listAnnotations and addAnnotation API access to non-admin roles in their environment as an interim measure.

Kernel software installed and running inside a Guest VM may exploit memory shared with the GPU Firmware to write data outside the Guest's virtualised GPU memory.

Kernel software installed and running inside a Guest VM may post improper commands to the GPU Firmware to write data outside the Guest's virtualised GPU memory.

Kernel software installed and running inside a Guest VM may exploit memory shared with the GPU Firmware to write data outside the Guest's virtualised GPU memory.

The Email Subscribers by Icegram Express WordPress plugin before 5.7.45 does not sanitise and escape some of its Workflow settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

The Email Subscribers by Icegram Express WordPress plugin before 5.7.45 does not sanitise and escape some of its form settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

The Email Subscribers by Icegram Express WordPress plugin before 5.7.45 does not sanitise and escape some of form settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

The Email Subscribers by Icegram Express WordPress plugin before 5.7.45 does not sanitise and escape some of its Text Block options, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

A vulnerability classified as critical was found in liujianview gymxmjpa 1.0. This vulnerability affects the function MenberDaoInpl of the file src/main/java/com/liujian/gymxmjpa/controller/MenberConntroller.java. The manipulation of the argument hyname leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical has been found in liujianview gymxmjpa 1.0. This affects the function MembertypeDaoImpl of the file src/main/java/com/liujian/gymxmjpa/controller/MembertypeController.java. The manipulation of the argument typeName leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in liujianview gymxmjpa 1.0. It has been rated as critical. Affected by this issue is the function LoosDaoImpl of the file src/main/java/com/liujian/gymxmjpa/controller/LoosController.java. The manipulation of the argument loosName leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in liujianview gymxmjpa 1.0. It has been declared as critical. Affected by this vulnerability is the function EquipmentDaoImpl of the file src/main/java/com/liujian/gymxmjpa/controller/EquipmentController.java. The manipulation of the argument hyname leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in liujianview gymxmjpa 1.0. It has been classified as critical. Affected is the function SubjectDaoImpl of the file src/main/java/com/liujian/gymxmjpa/controller/SubjectController.java. The manipulation of the argument subname leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in liujianview gymxmjpa 1.0 and classified as critical. This issue affects the function GoodsDaoImpl of the file src/main/java/com/liujian/gymxmjpa/controller/GoodsController.java. The manipulation of the argument goodsName leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability has been found in liujianview gymxmjpa 1.0 and classified as critical. This vulnerability affects the function CoachController of the file src/main/java/com/liujian/gymxmjpa/controller/CoachController.java. The manipulation of the argument coachName leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability, which was classified as problematic, has been found in 1902756969 reggie 1.0. Affected by this issue is some unknown functionality of the file /user/sendMsg of the component Phone Number Validation Handler. The manipulation of the argument code leads to information disclosure. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical was found in 1902756969 reggie 1.0. Affected by this vulnerability is the function upload of the file src/main/java/com/itheima/reggie/controller/CommonController.java. The manipulation of the argument file leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical has been found in 1902756969 reggie 1.0. Affected is the function download of the file src/main/java/com/itheima/reggie/controller/CommonController.java. The manipulation of the argument name leads to path traversal. It is possible to launch the attack 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 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.

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 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.

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.

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: ASoC: Intel: sof_sdw: Add space for a terminator into DAIs array The code uses the initialised member of the asoc_sdw_dailink struct to determine if a member of the array is in use. However in the case the array is completely full this will lead to an access 1 past the end of the array, expand the array by one entry to include a space for a terminator.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: iso: Always release hdev at the end of iso_listen_bis Since hci_get_route holds the device before returning, the hdev should be released with hci_dev_put at the end of iso_listen_bis even if the function returns with an error.

In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' 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.uw.fpmr, 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 FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d

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

In the Linux kernel, the following vulnerability has been resolved: block: RCU protect disk->conv_zones_bitmap Ensure that a disk revalidation changing the conventional zones bitmap of a disk does not cause invalid memory references when using the disk_zone_is_conv() helper by RCU protecting the disk->conv_zones_bitmap pointer. disk_zone_is_conv() is modified to operate under the RCU read lock and the function disk_set_conv_zones_bitmap() is added to update a disk conv_zones_bitmap pointer using rcu_replace_pointer() with the disk zone_wplugs_lock spinlock held. disk_free_zone_resources() is modified to call disk_update_zone_resources() with a NULL bitmap pointer to free the disk conv_zones_bitmap. disk_set_conv_zones_bitmap() is also used in disk_update_zone_resources() to set the new (revalidated) bitmap and free the old one.

In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently tagged_addr_ctrl_set() will consume an arbitrary value, 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. As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and rejects other values, a partial SETREGSET attempt will randomly succeed or fail depending on the value of the uninitialized value, and the exposure is significantly limited. 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 value of the tagged address ctrl will be retained. The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the user_aarch64_view used by a native AArch64 task to manipulate another native AArch64 task. As get_tagged_addr_ctrl() only returns an error value when called for a compat task, tagged_addr_ctrl_get() and tagged_addr_ctrl_set() should never observe an error value from get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that such an error would be unexpected, and error handlnig is not missing in either case.