VMware Workstation (14.x before 14.1.2) and Fusion (10.x before 10.1.2) contain multiple denial-of-service vulnerabilities that occur due to NULL pointer dereference issues in the RPC handler. Successful exploitation of these issues may allow an attacker with limited privileges on the guest machine trigger a denial-of-Service of their guest machine.

net/unix/af_unix.c in the Linux kernel 2.6.31.4 and earlier allows local users to cause a denial of service (system hang) by creating an abstract-namespace AF_UNIX listening socket, performing a shutdown operation on this socket, and then performing a series of connect operations to this socket.

drivers/scsi/bfa/bfa_core.c in the Linux kernel before 2.6.35 does not initialize a certain port data structure, which allows local users to cause a denial of service (system crash) via read operations on an fc_host statistics file.

NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager, where a malicious user in a guest VM can cause a NULL-pointer dereference, which may lead to denial of service.

VMware ESXi, Workstation, and Fusion contain a denial-of-service vulnerability due to certain guest options. A malicious actor with non-administrative privileges within a guest operating system may be able to exploit this issue by exhausting memory of the host process leading to a denial-of-service condition.

NVIDIA vGPU software for Linux contains a vulnerability where the software can dereference a NULL pointer. A successful exploit of this vulnerability might lead to denial of service and undefined behavior in the vGPU plugin.

NVIDIA GPU Driver for Windows and Linux contains a vulnerability where an improper check or improper handling of exception conditions might lead to denial of service.

VMware Tools for Windows (11.x.y prior to 11.3.0) contains a denial-of-service vulnerability in the VM3DMP driver. A malicious actor with local user privileges in the Windows guest operating system, where VMware Tools is installed, can trigger a PANIC in the VM3DMP driver leading to a denial-of-service condition in the Windows guest operating system.

The vCenter Server contains a denial-of-service vulnerability in the Analytics service. Successful exploitation of this issue may allow an attacker to create a denial-of-service condition on vCenter Server.

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged user can cause a null-pointer dereference, which may lead to denial of service.

NVIDIA vGPU manager contains a vulnerability in the vGPU plugin, in which input data is not validated, which may lead to unexpected consumption of resources, which in turn may lead to denial of service. This affects vGPU version 8.x (prior to 8.6) and version 11.0 (prior to 11.3).

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause a null-pointer dereference, which may lead to denial of service.

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unhandled return value can lead to a null-pointer dereference, which may lead to denial of service.

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an integer truncation can lead to an out-of-bounds read, which may lead to denial of service.

VMware Workstation (12.x before 12.5.8) and Fusion (8.x before 8.5.9) contain a guest RPC NULL pointer dereference vulnerability. Successful exploitation of this issue may allow attackers with normal user privileges to crash their VMs.

VMware ESXi 6.5 without patch ESXi650-201707101-SG, ESXi 6.0 without patch ESXi600-201706101-SG, ESXi 5.5 without patch ESXi550-201709101-SG, Workstation (12.x before 12.5.3), Fusion (8.x before 8.5.4) contain a NULL pointer dereference vulnerability. This issue occurs when handling guest RPC requests. Successful exploitation of this issue may allow attackers with normal user privileges to crash their VMs.

VMware Workstation Pro/Player 12.x before 12.5.3 contains a NULL pointer dereference vulnerability that exists in the SVGA driver. Successful exploitation of this issue may allow attackers with normal user privileges to crash their VMs.

VMware Tools for Windows (12.x.y prior to 12.1.5, 11.x.y and 10.x.y) contains a denial-of-service vulnerability in the VM3DMP driver. A malicious actor with local user privileges in the Windows guest OS, where VMware Tools is installed, can trigger a PANIC in the VM3DMP driver leading to a denial-of-service condition in the Windows guest OS.

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a NULL-pointer dereference may lead to denial of service.

NVIDIA vGPU software for Windows and Linux contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where a malicious user in the guest VM can cause a NULL-pointer dereference, which may lead to denial of service.

VMware ESXi (7.0 prior to ESXi70U1c-17325551), VMware Workstation (16.x prior to 16.0 and 15.x prior to 15.5.7), VMware Fusion (12.x prior to 12.0 and 11.x prior to 11.5.7) and VMware Cloud Foundation contain a denial of service vulnerability due to improper input validation in GuestInfo. A malicious actor with normal user privilege access to a virtual machine can crash the virtual machine's vmx process leading to a denial of service condition.

VMware Tools for macOS (11.x.x and prior before 11.1.1) contains a denial-of-service vulnerability in the Host-Guest File System (HGFS) implementation. Successful exploitation of this issue may allow attackers with non-admin privileges on guest macOS virtual machines to create a denial-of-service condition on their own VMs.

EMC VMware Player allows user-assisted attackers to cause a denial of service (unrecoverable application failure) via a long value of the ide1:0.fileName parameter in the .vmx file of a virtual machine. NOTE: third parties have disputed this issue, saying that write access to the .vmx file enables other ways of stopping the virtual machine, so no privilege boundaries are crossed

Insufficient control flow management in the Intel(R) Ethernet 500 Series Controller drivers for VMWare before version 1.11.4.0 and in the Intel(R) Ethernet 700 Series Controller drivers for VMWare before version 2.1.5.0 may allow an authenticated user to potentially enable a denial of service via local access.

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer handler, where an unprivileged user can cause improper restriction of operations within the bounds of a memory buffer cause an out-of-bounds read, which may lead to denial of service.

NVIDIA vGPU software for Windows and Linux contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where a NULL-pointer dereference may lead to denial of service.

NVIDIA GPU Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause a NULL-pointer dereference, which may lead to denial of service.

VMware Workstation (16.x prior to 16.2.2) and Horizon Client for Windows (5.x prior to 5.5.3) contains a denial-of-service vulnerability in the Cortado ThinPrint component. The issue exists in TrueType font parser. A malicious actor with access to a virtual machine or remote desktop may exploit this issue to trigger a denial-of-service condition in the Thinprint service running on the host machine where VMware Workstation or Horizon Client for Windows is installed.

VMware ESXi (6.7 before ESXi670-202004101-SG and 6.5 before ESXi650-202005401-SG), VMware Workstation (15.x before 15.1.0) and VMware Fusion (11.x before 11.1.0) contain a memory leak vulnerability in the VMCI module. A malicious actor with local non-administrative access to a virtual machine may be able to crash the virtual machine's vmx process leading to a partial denial of service.

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to denial of service.

Protection mechanism failure in the Intel(R) Ethernet 500 Series Controller drivers for VMware before version 1.10.0.1 may allow an authenticated user to potentially enable denial of service via local access.

VMware Workstation (15.x before 15.5.2) and Horizon Client for Windows (5.x and prior before 5.4.0) contain a denial-of-service vulnerability due to a heap-overflow issue in Cortado Thinprint. Attackers with non-administrative access to a guest VM with virtual printing enabled may exploit this issue to create a denial-of-service condition of the Thinprint service running on the system where Workstation or Horizon Client is installed.

VMware Workstation (15.x) and Horizon Client for Windows (5.x before 5.4.4) contain a denial of service vulnerability due to an out-of-bounds write issue in Cortado ThinPrint component. A malicious actor with normal access to a virtual machine may be able to exploit this issue to create a partial denial-of-service condition on the system where Workstation or Horizon Client for Windows is installed. Exploitation is only possible if virtual printing has been enabled. This feature is not enabled by default on Workstation but it is enabled by default on Horizon Client.

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one.

QEMU (aka Quick Emulator) built with a VMWARE VMXNET3 paravirtual NIC emulator support is vulnerable to crash issue. It could occur while reading Interrupt Mask Registers (IMR). A privileged (CAP_SYS_RAWIO) guest user could use this flaw to crash the QEMU process instance resulting in DoS.

TensorFlow is an end-to-end open source platform for machine learning. In affected versions providing a negative element to `num_elements` list argument of `tf.raw_ops.TensorListReserve` causes the runtime to abort the process due to reallocating a `std::vector` to have a negative number of elements. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/list_kernels.cc#L312) calls `std::vector.resize()` with the new size controlled by input given by the user, without checking that this input is valid. We have patched the issue in GitHub commit 8a6e874437670045e6c7dc6154c7412b4a2135e2. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.

A flaw was found in avahi 0.8-5. A reachable assertion is present in avahi_s_host_name_resolver_start function allowing a local attacker to crash the avahi service by requesting hostname resolutions through the avahi socket or dbus methods for invalid hostnames. The highest threat from this vulnerability is to the service availability.

libpspp-core.a in GNU PSPP through 2.0.1 allows attackers to cause a denial of service (var_set_leave_quiet assertion failure and application exit) via crafted input data, such as data that triggers a call from src/data/dictionary.c code into src/data/variable.c code.

In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items.

A reachable assertion issue was found in the USB EHCI emulation code of QEMU. It could occur while processing USB requests due to missing handling of DMA memory map failure. A malicious privileged user within the guest may abuse this flaw to send bogus USB requests and crash the QEMU process on the host, resulting in a denial of service.

TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service by exploiting a `CHECK`-failure coming from `tf.raw_ops.LoadAndRemapMatrix`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/d94227d43aa125ad8b54115c03cece54f6a1977b/tensorflow/core/kernels/ragged_tensor_to_tensor_op.cc#L219-L222) assumes that the `ckpt_path` is always a valid scalar. However, an attacker can send any other tensor as the first argument of `LoadAndRemapMatrix`. This would cause the rank `CHECK` in `scalar<T>()()` to trigger and terminate the process. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service by exploiting a `CHECK`-failure coming from the implementation of `tf.raw_ops.IRFFT`. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service by exploiting a `CHECK`-failure coming from the implementation of `tf.raw_ops.RFFT`. Eigen code operating on an empty matrix can trigger on an assertion and will cause program termination. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

In QEMU through 5.0.0, an assertion failure can occur in the network packet processing. This issue affects the e1000e and vmxnet3 network devices. A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service condition in net_tx_pkt_add_raw_fragment in hw/net/net_tx_pkt.c.

TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a denial of service via a `CHECK`-fail in `tf.raw_ops.CTCGreedyDecoder`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/1615440b17b364b875eb06f43d087381f1460a65/tensorflow/core/kernels/ctc_decoder_ops.cc#L37-L50) has a `CHECK_LT` inserted to validate some invariants. When this condition is false, the program aborts, instead of returning a valid error to the user. This abnormal termination can be weaponized in denial of service attacks. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

In the Linux kernel, the following vulnerability has been resolved: dma-buf/sync_file: Don't leak fences on merge failure Each add_fence() call does a dma_fence_get() on the relevant fence. In the error path, we weren't calling dma_fence_put() so all those fences got leaked. Also, in the krealloc_array failure case, we weren't freeing the fences array. Instead, ensure that i and fences are always zero-initialized and dma_fence_put() all the fences and kfree(fences) on every error path.