A flaw was found in ruby, where the date object was found to be vulnerable to a regular expression denial of service (ReDoS) during the parsing of dates. This flaw allows an attacker to hang a ruby application by providing a specially crafted date string. The highest threat to this vulnerability is system availability.

A flaw was found in dpdk in versions before 18.11.10 and before 19.11.5. A lack of bounds checking when copying ivdata from the VM guest memory into host memory can lead to a large buffer overflow. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in python-pip. Installing remote packages is vulnerable to directory traversal via Content-Disposition header by a malicious server.

Upstream issue:

https://github.com/pypa/pip/issues/6413

NTP is vulnerable to a denial of service, caused by an issue when relying on unauthenticated IPv4 time sources in ntpd. By predicting transmit timestamps for use in spoofed packets, a remote attacker could exploit this vulnerability to cause the daemon to crash or system time change.

A vulnerability was found in NTP. A security issue which enables an off-path attacker to prevent ntpd from synchronizing with NTP servers not using authentication. A server mode packet with spoofed source address sent to the client ntpd causes the next transmission to be rescheduled, even if the packet doesn't have a valid origin timestamp. If the packet is sent to the client frequently enough, it will stop polling the server and not be able to synchronize with it.

A flaw was found in Node.js, where affected Node.js versions converted carriage returns in HTTP request headers to a hyphen before parsing. This flaw leads to HTTP Request Smuggling as it is a non-standard interpretation of the header. The highest threat from this vulnerability is to confidentiality and integrity.

A flaw was found in the HDLCPPP module of the Linux kernel in versions before 5.9-rc7. Memory corruption and a read overflow is caused by improper input validation in the pppcpparsecr function which can cause the system to crash or cause a denial of service. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in the Linux kernel in versions before 5.9-rc7. Traffic between two Geneve endpoints may be unencrypted when IPsec is configured to encrypt traffic for the specific UDP port used by the GENEVE tunnel allowing anyone between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality.

An issue was discovered in Xen through 4.14.x. There are evtchnreset() race conditions. Uses of EVTCHNOPreset (potentially by a guest on itself) or XENDOMCTLsoftreset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.

An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smpmb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.

An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec "backdoor" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does.

An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-code order, which did not constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation options). The source code clearly violates the C rules, and thus should be considered vulnerable.

An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs, a CPU cache also needs writing back to memory after changes were made. Such writing back of cached data was missing in particular when splitting large page mappings into smaller granularity ones. A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. Xen versions from at least 3.2 onwards are affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible.

In non-standard configurations, a JPEG image created by JavaScript could have caused an internal variable to overflow, resulting in an out of bounds write, memory corruption, and a potentially exploitable crash.

Last updated 24 July 2024

An issue was discovered in LibVNCServer before 0.9.13. libvncserver/wsdecode.c can lead to a crash because of unaligned accesses in hybiReadAndDecode.

Impact By controlling the fill argument of tf.strings.asstring, a malicious attacker is able to trigger a format string vulnerability due to the way the internal format use in a printf call is constructed: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/asstringop.cc#L68-L74

This can result in unexpected output: python In [1]: tf.strings.asstring(input=[1234], width=6, fill='-') Out[1]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['1234 '], dtype=object)> In [2]: tf.strings.asstring(input=[1234], width=6, fill='+') Out[2]: <tf.Tensor: shape=(1,), dtype=string, numpy=array([' +1234'], dtype=object)> In [3]: tf.strings.asstring(input=[1234], width=6, fill="h") Out[3]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['%6d'], dtype=object)> In [4]: tf.strings.asstring(input=[1234], width=6, fill="d") Out[4]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['12346d'], dtype=object)> In [5]: tf.strings.asstring(input=[1234], width=6, fill="o") Out[5]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['23226d'], dtype=object)> In [6]: tf.strings.asstring(input=[1234], width=6, fill="x") Out[6]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['4d26d'], dtype=object)> In [7]: tf.strings.asstring(input=[1234], width=6, fill="g") Out[7]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['8.67458e-3116d'], dtype=object)> In [8]: tf.strings.asstring(input=[1234], width=6, fill="a") Out[8]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['0x0.00ff7eebb4d4p-10226d'], dtype=object)> In [9]: tf.strings.asstring(input=[1234], width=6, fill="c") Out[9]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['\xd26d'], dtype=object)> In [10]: tf.strings.asstring(input=[1234], width=6, fill="p") Out[10]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['0x4d26d'], dtype=object)> In [11]: tf.strings.asstring(input=[1234], width=6, fill='m') Out[11]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['Success6d'], dtype=object)>

However, passing in n or s results in segmentation fault.

Patches We have patched the issue in 33be22c65d86256e6826666662e40dbdfe70ee83 and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact The implementation of SparseFillEmptyRowsGrad uses a double indexing pattern: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/sparsefillemptyrowsop.cc#L263-L269

It is possible for reverseindexmap(i) to be an index outside of bounds of gradvalues, thus resulting in a heap buffer overflow.

Patches We have patched the issue in 390611e0d45c5793c7066110af37c8514e6a6c54 and will release a patch release for all affected versions.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact The implementation of dlpack.todlpack can be made to use uninitialized memory resulting in further memory corruption. This is because the pybind11 glue code assumes that the argument is a tensor: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/python/tfewrapper.cc#L1361

However, there is nothing stopping users from passing in a Python object instead of a tensor. python In [2]: tf.experimental.dlpack.todlpack([2]) ==1720623==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55b0ba5c410a in tensorflow::(anonymous namespace)::GetTensorFromHandle(TFETensorHandle, TFStatus) thirdparty/tensorflow/c/eager/dlpack.cc:46:7 #1 0x55b0ba5c38f4 in tensorflow::TFEHandleToDLPack(TFETensorHandle, TFStatus) thirdparty/tensorflow/c/eager/dlpack.cc:252:26 ...

The uninitialized memory address is due to a reinterpretcast https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/python/eager/pywraptensor.cc#L848-L850

Since the PyObject is a Python object, not a TensorFlow Tensor, the cast to EagerTensor fails.

Patches We have patched the issue in 22e07fb204386768e5bcbea563641ea11f96ceb8 and will release a patch release for all affected versions.

We recommend users to upgrade to TensorFlow 2.2.1 or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the Guest Additions toolset. The issue results from the use of unnecessary privileges when performing service operations. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the lsilogicRegisterWrite function. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the lsilogicRegisterWrite function. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the lsilogicR3ProcessMessageRequest function. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the lsilogicR3DiagRegDataWrite function. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the handling of Transmit Message Descriptors in the implementation of PCnet virtual network interfaces. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the handling of Transmit Message Descriptors in the implementation of PCnet virtual network interfaces. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the handling of Transmit Message Descriptors in the implementation of PCnet virtual network interfaces. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

This vulnerability allows local attackers to escalate privileges on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the implementation of the e1000 virtual network adapter. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.

Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 5.2.44, prior to 6.0.24 and prior to 6.1.12. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).

An issue was discovered in Flask-CORS (aka CORS Middleware for Flask) before 3.0.9. It allows ../ directory traversal to access private resources because resource matching does not ensure that pathnames are in a canonical format.