Vulnerabilidades

*** Pendiente de traducción *** A vulnerability was detected in Open5GS up to 2.7.6. Affected is the function diam_log_func of the file lib/diameter/common/init.c of the component CER Handler. The manipulation results in reachable assertion. The attack can be executed remotely. The exploit is now public and may be used. Upgrading to version 2.7.7 is able to address this issue. The patch is identified as c1a803516a3c0485696cb9bcca7a80ad857c7383. It is advisable to upgrade the affected component.

*** Pendiente de traducción *** A flaw was found in multicloud-integrations, a component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows an authenticated user, referred to as a tenant, to manipulate the GitOpsCluster controller. By exploiting this, a tenant can redirect sensitive spoke cluster bearer tokens from secure locations to a namespace they control. This unauthorized access to tokens can lead to the disclosure of critical information and bypass security policies within ArgoCD AppProjects.

*** Pendiente de traducción *** A flaw was found in the multicloud-integrations component. The Application propagation controller processes the `ocm-managed-cluster` annotation from an Application Custom Resource (CR) without proper validation. A tenant with permissions to create Applications on the hub cluster can exploit this to target arbitrary managed clusters. This can force ArgoCD on the spoke clusters to synchronize attacker-controlled manifests, leading to arbitrary code execution or privilege escalation on those clusters.

*** Pendiente de traducción *** A flaw was found in the multicloud-operators-channel component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows a compromised agent from a managed cluster to gain unauthorized access to sensitive information. Specifically, the agent can read all Secrets and ConfigMaps within any Channel namespace on the hub, potentially exposing credentials for other tenants' Git and Helm repositories. This could lead to significant information disclosure.

*** Pendiente de traducción *** A flaw was found in the multicloud-operators-channel component. This vulnerability allows a user with specific permissions to manipulate how the system handles sensitive information, known as Secrets, across different parts of the system (namespaces). By exploiting this, an attacker can modify these Secrets in unauthorized areas. This could lead to unauthorized access to information or elevated privileges within the system.

*** Pendiente de traducción *** A flaw was found in multicloud-operators-subscription. A privileged user, specifically a namespace administrator capable of creating Channel and Subscription resources, can exploit this vulnerability. By manipulating the Channel.Spec.SecretRef.Namespace field, the user can cause the system to copy sensitive Secret contents from other namespaces into their own, leading to information disclosure.

*** Pendiente de traducción *** In an UEFI, Lack of verified boot to certain FV may cause arbitrary code execution.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: check access to copy_file_range source with src mounter creds<br /> <br /> Commit 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices")<br /> allowed filesystems that implement the copy_file_range() f_op to decide<br /> if they want to access cross-sb copy from/to the same fs type.<br /> <br /> The same commit added checks to verify same sb copy for filesystems that<br /> implement -&gt;copy_file_range() and do not support cross-sb copy at the<br /> time, namely, to ceph, fuse and nfs.<br /> <br /> The two remaining fs which implement -&gt;copy_file_range(), cifs and<br /> overlayfs started to support cross-sb copy from this time.<br /> <br /> While overlayfs does support cross-sb copy when the two underlying files<br /> are on the same base fs, the copy operation on the two real files from<br /> two different overalyfs filesystems is performed with the mounter<br /> creds of the destination overlayfs and the read permission access hook<br /> for the source file was called with the wrong creds.<br /> <br /> This could cause either deny of access to copy which would otherwise be<br /> allowed (e.g. with splice) or allow read access to file which would<br /> otherwise be denied.<br /> <br /> Fix the latter case by explicitly verifying read access to source file<br /> with the source overlayfs mounter creds.<br /> <br /> The former case remains a quirk of cross-sb overlayfs copy, but<br /> userspace could fall back to regular copy so no harm done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size<br /> <br /> CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size<br /> from hardware without bounding it to the allocated BO region. If the HW<br /> field is larger than the queue&amp;#39;s control stack allocation, memcpy reads<br /> past the BO into adjacent GTT memory and can leak kernel data to userspace.<br /> <br /> Store the page-aligned control stack BO size in mqd_manager and clamp<br /> checkpoint copies and reported checkpoint sizes to<br /> min(cp_hqd_cntl_stack_size, mm-&gt;ctl_stack_size). Apply the same bound<br /> for multi-XCC v9.4.3 checkpoint layout.<br /> <br /> (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning<br /> <br /> The hand-rolled bit-scanning loop in the NCQ completion path has an<br /> infinite loop bug. When tag_mask has only high bits set (e.g.<br /> 0x80000000), the inner while loop left-shifts tag_mask until it<br /> overflows to 0. At that point !(0 &amp; 1) is always true and 0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: free mapping node on duplicate reloc root insert<br /> <br /> __add_reloc_root() allocates a mapping_node before inserting it into<br /> rc-&gt;reloc_root_tree. If rb_simple_insert() finds an existing entry, it<br /> returns the existing rb_node and leaves the newly allocated node unlinked.<br /> <br /> The error path then returns -EEXIST without freeing the new node. Since<br /> the node was never inserted into reloc_root_tree, the later cleanup in<br /> put_reloc_control() cannot find it either.<br /> <br /> Free the newly allocated node before returning -EEXIST.<br /> <br /> The callers currently assert that -EEXIST should not happen, so this is a<br /> defensive cleanup for an unexpected duplicate insert path. If the path is<br /> ever reached, the local allocation should still be released.

*** Pendiente de traducción *** A vulnerability was identified in Open5GS up to 2.7.1. This issue affects the function pcrf_rx_aar_cb of the file src/pcrf/pcrf-rx-path.c of the component Diameter Rx Handler. The manipulation of the argument num_of_media_component/num_of_sub leads to buffer overflow. The attack can be initiated remotely. The exploit is publicly available and might be used. Upgrading to version 2.7.2 is capable of addressing this issue. The identifier of the patch is 87b4e4535c77ded627cdb6f4e4e2e3ea761f40b7. It is recommended to upgrade the affected component.