SFCB (Small Footprint CIM Broker) as used in ESXi has an authentication bypass vulnerability. A malicious actor with network access to port 5989 on ESXi may exploit this issue to bypass SFCB authentication by sending a specially crafted request.
The slapmodrdn2mods function in modrdn.c in OpenLDAP 2.4.22 does not check the return value of a call to the smrnormalize function, which allows remote attackers to cause a denial of service (segmentation fault) and possibly execute arbitrary code via a modrdn call with an RDN string containing invalid UTF-8 sequences, which triggers a free of an invalid, uninitialized pointer in the slapmodsfree function, as demonstrated using the Codenomicon LDAPv3 test suite.
VMware ESXi (6.7 before ESXi670-201904101-SG and 6.5 before ESXi650-201903001), Workstation (15.x before 15.0.3 and 14.x before 14.1.6) and Fusion (11.x before 11.0.3 and 10.x before 10.1.6) contain an out-of-bounds read vulnerability in the pixel shader functionality. Successful exploitation of this issue may lead to information disclosure or may allow attackers with normal user privileges to create a denial-of-service condition on the host. Exploitation of this issue require an attacker to have access to a virtual machine with 3D graphics enabled. It is not enabled by default on ESXi and is enabled by default on Workstation and Fusion.
Directory traversal vulnerability in VMware ESXi 4.0 through 5.0, and ESX 4.0 and 4.1, allows remote attackers to delete arbitrary host OS files via unspecified vectors.
VMware ESXi, Workstation, and Fusion contain a use-after-free vulnerability in the UHCI USB controller. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.
VMware ESXi, Workstation, and Fusion contain a use-after-free vulnerability in the XHCI USB controller. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.
VMware Workstation 7.x before 7.1.6 and 8.x before 8.0.4, VMware Player 3.x before 3.1.6 and 4.x before 4.0.4, VMware Fusion 4.x before 4.1.3, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 allow user-assisted remote attackers to execute arbitrary code on the host OS or cause a denial of service (memory corruption) on the host OS via a crafted Checkpoint file.
ESXi 6.5 without patch ESXi650-201912104-SG and ESXi 6.7 without patch ESXi670-202004103-SG do not properly neutralize script-related HTML when viewing virtual machines attributes. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 8.3.
Directory traversal vulnerability in VMWare ESXi 3.5 before ESXe350-200810401-O-UG and ESX 3.5 before ESX350-200810201-UG allows administrators with the Datastore.FileManagement privilege to gain privileges via unknown vectors.
VMware Workstation 8.x before 8.0.3, VMware Player 4.x before 4.0.3, VMware Fusion 4.x through 4.1.2, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 do not properly configure the virtual floppy device, which allows guest OS users to cause a denial of service (out-of-bounds write operation and VMX process crash) or possibly execute arbitrary code on the host OS by leveraging administrative privileges on the guest OS.
VMware Workstation 8.x before 8.0.3, VMware Player 4.x before 4.0.3, VMware Fusion 4.x before 4.1.2, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 do not properly register SCSI devices, which allows guest OS users to cause a denial of service (invalid write operation and VMX process crash) or possibly execute arbitrary code on the host OS by leveraging administrative privileges on the guest OS.
Buffer overflow in the openwsman management service in VMware ESXi 3.5 and ESX 3.5 allows remote authenticated users to gain privileges via an "invalid Content-Length."
VMware ESXi (ESXi 6.5 without patch ESXi650-201707101-SG), Workstation (12.x before 12.5.7) and Fusion (8.x before 8.5.8) contain an out-of-bounds write vulnerability in SVGA device. This issue may allow a guest to execute code on the host.
ESXi, Workstation, Fusion, VMRC and Horizon Client contain a use-after-free vulnerability in the virtual sound device. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 8.5.
VMware ESXi 6.7 without ESXi670-201811401-BG and VMware ESXi 6.5 without ESXi650-201811301-BG, VMware ESXi 6.0 without ESXi600-201811401-BG, VMware Workstation 15, VMware Workstation 14.1.3 or below, VMware Fusion 11, VMware Fusion 10.1.3 or below contain uninitialized stack memory usage in the vmxnet3 virtual network adapter which may allow a guest to execute code on the host.
This vulnerability allows local attackers to escalate privileges on affected installations of VMware Workstation. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the implementation of SVGA3D commands. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the hypervisor.
VMware ESXi (6.0 before ESXi600-201711101-SG, 5.5 ESXi550-201709101-SG), Workstation (12.x before 12.5.8), and Fusion (8.x before 8.5.9) contain a vulnerability that could allow an authenticated VNC session to cause a stack overflow via a specific set of VNC packets. Successful exploitation of this issue could result in remote code execution in a virtual machine via the authenticated VNC session. Note: In order for exploitation to be possible in ESXi, VNC must be manually enabled in a virtual machine's .vmx configuration file. In addition, ESXi must be configured to allow VNC traffic through the built-in firewall.
VMware ESXi (6.5 before ESXi650-201710401-BG), Workstation (12.x before 12.5.8), and Fusion (8.x before 8.5.9) contain a vulnerability that could allow an authenticated VNC session to cause a heap overflow via a specific set of VNC packets resulting in heap corruption. Successful exploitation of this issue could result in remote code execution in a virtual machine via the authenticated VNC session. Note: In order for exploitation to be possible in ESXi, VNC must be manually enabled in a virtual machine's .vmx configuration file. In addition, ESXi must be configured to allow VNC traffic through the built-in firewall.
VMware ESXi contains a memory corruption vulnerability that exists in the way it handles a network socket. A malicious actor with local access to ESXi may exploit this issue to corrupt memory leading to an escape of the ESXi sandbox.
VMware ESXi contains an out-of-bounds write vulnerability. A malicious actor with privileges within the VMX process may trigger an out-of-bounds write leading to an escape of the sandbox.
This vulnerability allows local attackers to escalate privileges on affected installations of VMware Workstation. 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 xHCI component. When parsing Isoch Transfer Descriptor (TD), the process does not properly validate user-supplied data that can result in a write past the end of an allocated object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.
VMware ESXi (7.0 before ESXi70U1b-17168206, 6.7 before ESXi670-202011101-SG, 6.5 before ESXi650-202011301-SG), Workstation (15.x before 15.5.7), Fusion (11.x before 11.5.7) contain a use-after-free vulnerability in the XHCI USB controller. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host.
This vulnerability allows local attackers to escalate privileges on affected installations of VMware Workstation. 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 the SVGA DXInvalidateContext command. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor.
VMware ESXi, Workstation, and Fusion contain a heap out-of-bounds write vulnerability in the USB 2.0 controller (EHCI). A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.
The storage controllers on VMware ESXi, Workstation, and Fusion have out-of-bounds read/write vulnerability. A malicious actor with access to a virtual machine with storage controllers enabled may exploit this issue to create a denial of service condition or execute code on the hypervisor from a virtual machine in conjunction with other issues.
lgtosync.sys in VMware Workstation 9.x before 9.0.3, VMware Player 5.x before 5.0.3, VMware Fusion 5.x before 5.0.4, VMware ESXi 4.0 through 5.1, and VMware ESX 4.0 and 4.1, when a 32-bit Windows guest OS is used, allows guest OS users to gain guest OS privileges via an application that performs a crafted memory allocation.
If igb's SR-IOV and promiscuous mode are enabled and the interface receives a tag VLAN packet, this will result in a null pointer dereference. To fix this, we will backport upstream commit 31b24b95 to ensure that vlangroreceive is only used if vlans have been registered to the adapter structure.
[ This fixes bugzilla entry 15582 -Eric Dumazet]
It matters if CONFIGPCIIOV is enabled, e.g. grep -ir SRIOV drivers/net/igb/.
Upstream commit: http://git.kernel.org/linus/31b24b95
References: https://bugzilla.kernel.org/showbug.cgi?id=15582
VMware Workstation 8.x before 8.0.4, VMware Player 4.x before 4.0.4, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 allow remote attackers to cause a denial of service (guest OS crash) via crafted traffic from a remote virtual device.
Tavis Ormandy and Julien Tinnes, Google Security Team reported that Kernels <= 2.6.18.8 are vulnerable to a NULL pointer dereference issue when using MSGMORE on udp sockets.
Fixed upstream already by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1e0c14f49d6b393179f423abbac47f85618d3d46
Acknowledgements:
Red Hat would like to thank Tavis Ormandy and Julien Tinnes of the Google Security Team for responsibly reporting this flaw.
VMware ESXi 4.0 and 4.1 and ESX 4.0 and 4.1 allow remote attackers to cause a denial of service (socket exhaustion) via unspecified network traffic.