It was found that the cgroup limitation of system resources used by Kubernetes can be bypassed. A guest pod can be used to consume a large amount of system memory.
A suggested upstream patch set:
https://lore.kernel.org/netdev/20190401113110.GA20717@hmswarspite.think-freely.org/T/#u
A race condition in perfeventopen() allows local attackers to leak sensitive data from setuid programs. As no relevant locks (in particular the credguardmutex) are held during the ptracemayaccess() call, it is possible for the specified target task to perform an execve() syscall with setuid execution before perfeventalloc() actually attaches to it, allowing an attacker to bypass the ptracemayaccess() check and the perfeventexittask(current) call that is performed in installexeccreds() during privileged execve() calls.
An infinite loop issue was found in the vhostnet kernel module in Linux Kernel up to and including v5.1-rc6, while handling incoming packets in handlerx(). It could occur if one end sends packets faster than the other end can process them. A guest user, maybe remote one, could use this flaw to stall the vhostnet kernel thread, resulting in a DoS scenario.
A flaw was found in the Linux kernel vfio interface implementation that permits violation of the user's locked memory limit. If a device is bound to a vfio driver, such as vfio-pci, and the local attacker is administratively granted ownership of the device, it may cause a system memory exhaustion and thus a denial of service (DoS).
References:
https://seclists.org/oss-sec/2019/q2/6
A suggested fix:
https://lore.kernel.org/lkml/155414977872.12780.13728555131525362206.stgit@gimli.home/T/#u
A flaw that allowed an attacker to corrupt memory and possibly escalate privileges was found in the mwifiex kernel module while connecting to a malicious wireless network.
Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Installer component (CVE-2018-2627). Upstream has CVSS scored this issue as: 7.5/CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
It was discovered that the JPEGImageReader implementation in the 2D component of OpenJDK would, in certain cases, read all image data even if that was not used later. A specially crafted image could cause a Java application to temporarily use an excessive amount of CPU and memory.
It was discovered that the JAR (Java ARchive) verifier in the Security component of OpenJDK did not correctly handle files inside archives with missing digest. An attacker could possibly use this flaw to manipulate content of a singed JAR, bypassing intended verification.
It was discovered that the Hotspot component of OpenJDK did not properly check for integer overflows when generating range check loop predicates. An untrusted Java application or applet could use this flaw to corrupt JVM memory and cause it to crash or, possibly, execute arbitrary code, bypassing Java sandbox restrictions.
It was discovered that the Nashorn JavaScript engine in the Scripting component of OpenJDK could allow JavaScripts to access Java APIs even when access to Java APIs was disabled. An untrusted JavaScript executed by Nashorn could use this flaw to bypass intended restrictions.
A flaw was found in the way the Hotspot component of OpenJDK processed extraneous brackets in function signatures. An untrusted Java application or applet could use this flaw to bypass Java certain sandbox restrictions.
Oracle Java SE 7u151 and 8u141 fixes an unspecified vulnerability in the JavaFX component (CVE-2017-10086). Upstream has CVSS scored this issue as: 9.6/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixJAVA
It was discovered that the implementation of the ThreadPoolExecutor class in the java.util.concurrent package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the ServiceRegistry class in the ImageIO component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the AsynchronousChannelGroupImpl class in the java.nio.channels package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the TransformerException class in the JAXP component of OpenJDK failed to properly perform access control checks, related to handling of the DTM exceptions. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the JAXP component of OpenJDK failed to restrict access to certain internal classes. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
The fix for this issue adds the following packages to the package.access security property, which defines the list of restricted internal packages not accessible to untrusted code:
com.sun.org.apache.xml.internal.resolver.helpers. com.sun.org.apache.xml.internal.resolver.readers.
It was discovered that the DCG (Distributed Garbage Collector) implementation in the RMI component of OpenJDK failed to correctly handle references. A remote attacker could possibly use this flaw to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
Oracle Java SE 6u161, 7u151, and 8u141 fixes an unspecified vulnerability in the Deployment component (CVE-2017-10105). Upstream has CVSS scored this issue as: 4.3/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixJAVA
It was discovered that the implementation of the ActivationID class in the RMI component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the BasicAttribute class in OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted serialized input stream could cause JVM to consume an excessive amount of memory.
It was discovered that the implementation of the CodeSource class in OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. An untrusted Java application or applet could use this flaw to cause JVM to allocate an excessive amount of memory, bypassing certain Java sandbox restrictions.
It was discovered that the implementation of the ImageWatched class in the AWT component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.