Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** The CloudStack Backup plugin has an improper authorization logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and has access to specific APIs can list backups from any account in the environment. This vulnerability does not allow them to see the contents of the backup.<br /> <br /> Users are recommended to upgrade to version 4.22.0.1, which fixes the issue.

*** Pendiente de traducción *** The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can create new VMs using backups of any other user of the environment.<br /> <br /> Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue.

*** Pendiente de traducción *** The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can restore a volume from any other user&amp;#39;s backups and attach the volume to their own VMs.<br /> <br /> Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue.

*** Pendiente de traducción *** Missing MinIO policy cleanup on bucket deletion via Apache CloudStack allows users to retain access to buckets which they previously owned. If another user creates a new bucket with the same name, the previous owners can gain unauthorized read and write access to it by using the previously generated access and secret keys.<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.