what you don't know can hurt you

VMware ESXi Use-After-Free / Out-Of-Bounds Access

VMware ESXi Use-After-Free / Out-Of-Bounds Access
Posted Jul 17, 2020
Authored by Google Security Research, Cfir Cohen

Several security issues have been identified in the VMware ESIx virtual machine monitor (VMM). A use-after-free (UAF) vulnerability in PVNVRAM, a missing return value check in EHCI USB controller leading to private heap information disclosure, and several out-of-bounds reads.

tags | advisory, info disclosure
advisories | CVE-2020-3960, CVE-2020-3963, CVE-2020-3964, CVE-2020-3965
MD5 | d2417f8af8ebed99ebd6fdfff7a2c153

VMware ESXi Use-After-Free / Out-Of-Bounds Access

Change Mirror Download
We identified several security issues in the ESIx virtual machine
monitor (VMM): a use-after-free (UAF) vulnerability in PVNVRAM, a
missing return value check in EHCI USB controller leading to private
heap information disclosure, and several OOB reads.

All issues have been fixed by the vendor. Links to the patches are
provided below.

ESXi PVNVRAM Use After Free [CVE-2020-3963]
The paravirtualized NVRAM device supports read / write / find-next
operations on variables stored in its variables store.

The find-next operation (opcode 0xD2) allows guest firmware to
enumerate all variables in the store by querying for the next variable
in the store. PVNVRAM stores a raw pointer to the last returned
variable. In most places that update the variable store, this pointer
is properly cleared, however, in the write operation (opcode 0xD3),
there’s a flow that updates / deletes an existing variable, where this
last_search_value pointer is not cleared.

This leads to a situation where the dangling pointer is used in
subsequent find-next operations. We were able to trigger this UAF from
the guest, and confirmed (using gdb) that the dangling pointer is
indeed used after free.


ESXi EHCI qTD data leak [CVE-2020-3964]
The EHCI USB controller processes queue element transfer descriptors
(qTD), as described in section 3.5 of the EHCI specification. We found
that the implementation in this case processes guest-controlled qTDs.

Each descriptor has up to 5 buffer pointers that together hold the USB
request block (URB):

+---------Queue Element Transfer Descriptor Block +
| Next qTD pointer | 0 | T |
| Alternate Next qTD Pointer | 0 | T |
| Total Bytes to Transfer | C_Page | Cerr | Status |
| Buffer Pointer (page 0) | Current Offset |
| Buffer Pointer (page 1) | Reserved |
| Buffer Pointer (page 2) | Reserved |
| Buffer Pointer (page 3) | Reserved |
| Buffer Pointer (page 4) | Reserved |

The function EhciReadTDBuffer() (name identified from log string)
reads the URB contents into a heap allocated buffer. Unfortunately,
the return value of ReadBytes is not checked. A guest can cause this
function to fail by passing a GPA value of zero (or, in the 64bit
addressing case, a non-canonical address >= 0x8000’0000'0000). This
leads to a case where an attached USB device processes a URB with
uninitialized heap data.

We successfully exploited this to leak VMM heap data by sending a SCSI
WRITE command to a USB mass storage device.

Writes to a USB mass storage device are encoded in two qTDs: the first
holds the SCSI WRITE header, and the second holds the data to be

For example, the following operations in the guest:

$ perl -e "print 'a'x2000;" > aaaa
$ sudo dd if=aaaa of=/dev/sdb1 bs=512 count=8

Result in the following qTDs:

# First qTD of size 0x1f:
# "USBC" signature is the CBW packet header set by
# usb_stor_Bulk_transport() in drivers/usb/storage/transport.c.
# 0x2A is SCSI WRITE (10) command in the CDB buffer.
# 0x08 is the transfer length in sectors (8 * 0x200 = 0x1000).
Thread 1 hit Breakpoint 1, xxxx in ?? ()
EhciReadTDBuffer, buffer pointer 1 = 34a89000, size = 1f

Thread 1 hit Breakpoint 2, xxxx in ?? ()
0x65f38a8: 0x55 0x53 0x42 0x43 0x5f 0x03 0x00 0x00
0x65f38b0: 0x00 0x10 0x00 0x00 0x00 0x00 0x0a 0x2a
0x65f38b8: 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x08
0x65f38c0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

# Second qTD of size 0x1000 holds the "aaaaaa" data:
Thread 1 hit Breakpoint 1, xxxx in ?? ()
EhciReadTDBuffer, buffer pointer 1 = 33a82000, size = 1000

Thread 1 hit Breakpoint 2, xxxx in ?? ()
0x65e1728: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61
0x65e1730: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61
0x65e1738: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61
0x65e1740: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61

By failing ReadBytes() in the second qTD, we write previous heap data
to the disk. We verified VUsb_NewUrb() mallocs the URB buffer, and
doesn’t memset the data buffer to zeros. We confirmed that by reading
back the disk contents, the hypervisor was leaking uninitialized heap


ESXi XHCI OOB read access [CVE-2020-3965]
XHCI USB controller reads the DCBs from the guest by mapping a guest
page and iterating over values in it based on a bit field value.

There was insufficient validation on the bit field value: the map size
may be out of sync with the loop counter. A guest can supply a size
value of 0x40, with a bit field value of 0xffffffff. This causes the
loop to copy 32 elements out of the mapped page, which is outside the
bounds of the mapped region


ESXi NVME OOB read access [CVE-2020-3960]
The NVME controller does not properly handle namespace 0 in the
nvme_admin_identify handler. NSID of 0 minus one underflows and leads
to an OOB read access.


These vulnerabilities were discovered and reported to VMware by Cfir
Cohen of the Google Cloud security team.


4-20 - Vulnerabilities disclosed to VMware security team
4-26 - Vendor confirms the issues
6-09 - VMSA-2020-0012 fixes NVME issue
6-23 - VMSA-2020-0015 fixes PVNVRAM, EHCI, XHCI issues
7-16 - Public disclosure

We’d like to thank the VMware security team for their prompt response.

Login or Register to add favorites

File Archive:

October 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    25 Files
  • 2
    Oct 2nd
    13 Files
  • 3
    Oct 3rd
    1 Files
  • 4
    Oct 4th
    1 Files
  • 5
    Oct 5th
    15 Files
  • 6
    Oct 6th
    15 Files
  • 7
    Oct 7th
    15 Files
  • 8
    Oct 8th
    11 Files
  • 9
    Oct 9th
    3 Files
  • 10
    Oct 10th
    1 Files
  • 11
    Oct 11th
    1 Files
  • 12
    Oct 12th
    8 Files
  • 13
    Oct 13th
    12 Files
  • 14
    Oct 14th
    23 Files
  • 15
    Oct 15th
    4 Files
  • 16
    Oct 16th
    13 Files
  • 17
    Oct 17th
    1 Files
  • 18
    Oct 18th
    1 Files
  • 19
    Oct 19th
    27 Files
  • 20
    Oct 20th
    41 Files
  • 21
    Oct 21st
    18 Files
  • 22
    Oct 22nd
    16 Files
  • 23
    Oct 23rd
    2 Files
  • 24
    Oct 24th
    1 Files
  • 25
    Oct 25th
    1 Files
  • 26
    Oct 26th
    17 Files
  • 27
    Oct 27th
    19 Files
  • 28
    Oct 28th
    29 Files
  • 29
    Oct 29th
    13 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By