Vulnerabilities

The optional extension component TinkerpopClientService is missing the Restricted annotation with the Execute Code Required Permission in Apache NiFi 2.0.0-M1 through 2.8.0. The TinkerpopClientService supports configuration of ByteCode Submission for the Script Submission Type, enabling Groovy Script execution in the service prior to submitting the query. The missing Restricted annotation allows users without the Execute Code Permission to configure the Service in installations that use fine-grained authorization and have the optional TinkerpopClientService installed. Apache NiFi installations that do not have the nifi-other-graph-services-nar installed are not subject to this vulnerability. Upgrading to Apache NiFi 2.9.0 is the recommended mitigation.

Dell PowerScale OneFS versions 9.5.0.0 through 9.5.1.6, 9.6.0.0 through 9.7.1.13, 9.8.0.0 through 9.10.1.5 and 9.11.0.0 through 9.12.0.1 contains an Insufficient Logging vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information tampering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: fix for dma-fence safe access rules<br /> <br /> Commit 506aa8b02a8d6 ("dma-fence: Add safe access helpers and document<br /> the rules") details the dma-fence safe access rules. The most common<br /> culprit is that drm_sched_fence_get_timeline_name may race with<br /> group_free_queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tests: shmem: Hold reservation lock around vmap/vunmap<br /> <br /> Acquire and release the GEM object&amp;#39;s reservation lock around vmap and<br /> vunmap operations. The tests use vmap_locked, which led to errors such<br /> as show below.<br /> <br /> [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0<br /> <br /> [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350<br /> <br /> [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370<br /> <br /> [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330<br /> <br /> Only export the new vmap/vunmap helpers for Kunit tests. These are<br /> not interfaces for regular drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"<br /> <br /> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.<br /> <br /> OP-TEE logic in U-Boot automatically injects a reserved-memory<br /> node along with optee firmware node to kernel device tree.<br /> The injection logic is dependent on that there is no manually<br /> defined optee node. Having the node in zynqmp.dtsi effectively<br /> breaks OP-TEE&amp;#39;s insertion of the reserved-memory node, causing<br /> memory access violations during runtime.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing<br /> <br /> The recent refactoring of where runtime PM is enabled done in commit<br /> f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to<br /> avoid imbalance") made the fact that when we do a pm_runtime_disable()<br /> in the error paths of probe() we can trigger a runtime disable which in<br /> turn results in duplicate clock disables. This is particularly likely<br /> to happen when there is missing or broken DT description for the flashes<br /> attached to the controller.<br /> <br /> Early on in the probe function we do a pm_runtime_get_noresume() since<br /> the probe function leaves the device in a powered up state but in the<br /> error path we can&amp;#39;t assume that PM is enabled so we also manually<br /> disable everything, including clocks. This means that when runtime PM is<br /> active both it and the probe function release the same reference to the<br /> main clock for the IP, triggering warnings from the clock subsystem:<br /> <br /> [ 8.693719] clk:75:7 already disabled<br /> [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb<br /> ...<br /> [ 8.694261] clk_core_disable+0xa0/0xb4 (P)<br /> [ 8.694272] clk_disable+0x38/0x60<br /> [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi]<br /> [ 8.694309] platform_probe+0x5c/0xa4<br /> <br /> Dealing with this issue properly is complicated by the fact that we<br /> don&amp;#39;t know if runtime PM is active so can&amp;#39;t tell if it will disable the<br /> clocks or not. We can, however, sidestep the issue for the flash<br /> descriptions by moving their parsing to when we parse the controller<br /> properties which also save us doing a bunch of setup which can never be<br /> used so let&amp;#39;s do that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()<br /> <br /> rtw8822b_set_antenna() can be called from userspace when the chip is<br /> powered off. In that case a WARNING is triggered in<br /> rtw8822b_config_trx_mode() because trying to read the RF registers<br /> when the chip is powered off returns an unexpected value.<br /> <br /> Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when<br /> the chip is powered on.<br /> <br /> ------------[ cut here ]------------<br /> write RF mode table fail<br /> WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]<br /> CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1<br /> Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021<br /> RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]<br /> Call Trace:<br /> <br /> rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b]<br /> rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb]<br /> ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3]<br /> nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]<br /> ? netdev_run_todo+0x63/0x550<br /> genl_family_rcv_msg_doit+0xfc/0x160<br /> genl_rcv_msg+0x1aa/0x2b0<br /> ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]<br /> ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]<br /> ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x59/0x110<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x285/0x3c0<br /> ? __alloc_skb+0xdb/0x1a0<br /> netlink_sendmsg+0x20d/0x430<br /> ____sys_sendmsg+0x39f/0x3d0<br /> ? import_iovec+0x2f/0x40<br /> ___sys_sendmsg+0x99/0xe0<br /> ? refill_obj_stock+0x12e/0x240<br /> __sys_sendmsg+0x8a/0xf0<br /> do_syscall_64+0x81/0x970<br /> ? do_syscall_64+0x81/0x970<br /> ? ksys_read+0x73/0xf0<br /> ? do_syscall_64+0x81/0x970<br /> ? count_memcg_events+0xc2/0x190<br /> ? handle_mm_fault+0x1d7/0x2d0<br /> ? do_user_addr_fault+0x21a/0x690<br /> ? exc_page_fault+0x7e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tests: shmem: Hold reservation lock around madvise<br /> <br /> Acquire and release the GEM object&amp;#39;s reservation lock around calls<br /> to the object&amp;#39;s madvide operation. The tests use<br /> drm_gem_shmem_madvise_locked(), which led to errors such as show below.<br /> <br /> [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140<br /> <br /> Only export the new helper drm_gem_shmem_madvise() for Kunit tests.<br /> This is not an interface for regular drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tests: shmem: Hold reservation lock around purge<br /> <br /> Acquire and release the GEM object&amp;#39;s reservation lock around calls<br /> to the object&amp;#39;s purge operation. The tests use<br /> drm_gem_shmem_purge_locked(), which led to errors such as show below.<br /> <br /> [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740<br /> <br /> Only export the new helper drm_gem_shmem_purge() for Kunit tests.<br /> This is not an interface for regular drivers.

Lack of proper authorization implementation in the CashDro 3 web administration panel, version 24.01.00.26. The backend lacks authorization controls, leaving security entirely to the frontend. By modifying the binary string in the ‘Permissions’ field of the JSON response, an attacker could escalate privileges and gain full administrative access. This vulnerability allows all restrictions to be bypassed and completely compromises system management.

Instances deployed via the Proxmox extension allow unauthorized access to instances belonging to other tenants.<br /> <br /> <br /> <br /> <br /> This issue affects Apache CloudStack: from 4.21.0.0 through 4.22.0.0.<br /> <br /> <br /> <br /> <br /> The Proxmox extension for CloudStack improperly uses a user-editable instance setting, proxmox_vmid, to associate CloudStack instances with Proxmox virtual machines. Because this value is not restricted or validated against tenant ownership and Proxmox VM IDs are predictable, a non-privileged attacker can modify the setting to reference a VM belonging to another account. This allows unauthorized cross-tenant access and enables full control over the targeted VM, including starting, stopping, and destroying the virtual machine.<br /> <br /> <br /> <br /> <br /> Users are recommended to upgrade to version 4.22.0.1, which fixes this issue.<br /> <br /> <br /> <br /> <br /> As a workaround for the existing installations, editing of the proxmox_vmid instance detail by users can be prevented by adding this detail name to the global configuration parameter - user.vm.denied.details.

Account users are allowed by default to register templates to be downloaded directly to the primary storage for deploying instances using the KVM hypervisor. Due to missing file name sanitization, an attacker can register malicious templates to execute arbitrary code on the KVM hosts. This can result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of the KVM-based infrastructure managed by CloudStack.<br /> <br /> <br /> Users are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.