Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service.
External References:
https://github.com/google/guava/wiki/CVE-2018-10237 https://groups.google.com/forum/#!topic/guava-announce/xqWALw4W1vs/discussion
Upstream Patch:
https://github.com/google/guava/commit/7ec8718f1e6e2814dabaa4b9f96b6b33a813101c
A flaw was found in the Linux kernel with files on tmpfs and hugetlbfs. An attacker is able to bypass file permissions on filesystems mounted with tmpfs/hugetlbs to modify a file and possibly disrupt normal system behaviour.
At this time there is an understanding there is no crash or priviledge escalation but the impact of modifications on these filesystems of files in production systems may have adverse affects.
A suggested upstream patch:
https://lore.kernel.org/lkml/20181126173452.26955-1-aarcange@redhat.com/T/#u
An upstream patchset:
9e368259ad988356c4c95150fafd1a06af095d98 userfaultfd: use ENOENT instead of EFAULT if the atomic copy user fails 5b51072e97d587186c2f5390c8c9c1fb7e179505 userfaultfd: shmem: allocate anonymous memory for MAPPRIVATE shmem 29ec90660d68bbdd69507c1c8b4e33aa299278b1 userfaultfd: shmem/hugetlbfs: only allow to register VMMAYWRITE vmas e2a50c1f64145a04959df2442305d57307e5395a userfaultfd: shmem: add isize checks dcf7fe9d89763a28e0f43975b422ff141fe79e43 userfaultfd: shmem: UFFDIOCOPY: set the page dirty if VMWRITE is not set
A flaw was found in The Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted ELF file. This can occur during execution of nm.
References: https://sourceware.org/bugzilla/showbug.cgi?id=23361
The following cri-o packages as released for Red Hat OpenShift Container Platform 4.9.48, 4.10.31 and 4.11.6 included an incorrect version of cri-o that was missing the fix for CVE-2022-27652:
- cri-o-1.22.5-10.rhaos4.9.gitd14fede.el8 via RHBA-2022:6316 (https://access.redhat.com/errata/RHBA-2022:6316) - cri-o-1.23.3-16.rhaos4.10.gitd7c9b35.el8 via RHBA-2022:6257 (https://access.redhat.com/errata/RHBA-2022:6257) - cri-o-1.24.2-7.rhaos4.11.gitca400e0.el8 via RHBA-2022:6658 (https://access.redhat.com/errata/RHBA-2022:6658)
The regressed CVE-2022-27652 was previously corrected in Red Hat OpenShift Container Platform 4.9.41 and 4.10.12 via RHBA-2022:5433 and RHSA-2022:1600, respectively.
CVE-2022-3466 was assigned to this security regression and it is specific to the cri-o packages produced by Red Hat. The original issue could allow an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. For more details about the original issue, see:
https://access.redhat.com/security/cve/CVE-2022-27652 https://bugzilla.redhat.com/showbug.cgi?id=CVE-2022-27652
Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication.
Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system.
A flaw was found in the RMI registry implementation in the RMI component of OpenJDK. Incorrect handling of the server-side dispatch could lead to selection of an incorrect skeleton class.
An out-of-bounds read flaw was found in the Poppler library as demonstrated by pdfunite. This may result in a denial of service or other undefined behavior. This flaw may be exploitable when a victim opens a specially crafted PDF file.
Upstream Patch: https://cgit.freedesktop.org/poppler/poppler/commit/?id=004e3c10df0abda214f0c293f9e269fdd979c5ee
A flaw was found in openshift-ansible. OpenShift Container Platform (OCP) 3.11 is too permissive in the way it specified CORS allowed origins during installation. An attacker, able to man-in-the-middle the connection between the user's browser and the openshift console, could use this flaw to perform a phishing attack. The main threat from this vulnerability is data confidentiality.