Talos Vulnerability Report


VMware VNC Lock Count Denial of Service Vulnerability

March 15, 2018
CVE Number



An exploitable Denial of Service vulnerability exists in the remote management functionality of VMware . A large amount of VNC connections can cause an exception in the server to trigger, resulting in a shutdown of the virtual machine. An attacker can initiate VNC sessions to trigger this vulnerability.

Tested Versions

VMware Workstation Pro 12.5.7, Linux/Windows

Product URLs


CVSSv3 Score

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H


CWE-772: Missing Release of Resource after Effective Lifetime


VMware’s VNC implementation is used for remote management, remote access, and automation purposes in VMware products, such as Workstation, Player, and ESXi, which share a common VMW VNC code base between them all.

Since the VMware VNC server is naturally multi-threaded, there are locks and semaphores and mutexes to deal with shared variables. The VNC server also maintains a global variable that indicates the amount of locks that are currently used, that is incremented by certain events. The relevant disassembly is listed below:

	sub rsp, 8 
	mov eax, 1 
	lock xadd cs:MxLockCounter, eax ; This is the only xref 
	mov rdx, cs:AtomicUseFence_ptr 
	cmp byte ptr [rdx], 0 
	jnz short big_num_cmp
	cmp eax, 0FFFFFFh
	jz too_many_locks
too_many_locks: ; "MXUserAllocSerialNumber" 
	lea rsi, aMxuserallocser 
	lea rdi, aSTooManyLocks ; "%s: too many locks!\n" 
	xor eax, eax 
	call Log_Error
	call kill_all_threads

The above truncated disassembly is called at least twice in the course of any VNC connection, which, to summarize, just checks to makes sure there isn’t a really large number of locks, since that would be bad. Presumably.

Regardless, the important thing to note here is that the incrementing instruction (lock xadd cs:MxLockCounter, eax;) is the only cross-reference to the MxLockCounter global variable, meaning it never gets decremented. Thus, as long as and attacker can initiate a bunch of TCP connection to the VNC server (each successful connection increments it twice), without even sending any other datagrams, an attacker can eventually shutdown the connected virtual machine.

Exploit Proof-of-Concept

# There are obviously better ways to do this
for x in `seq 0 $(( 0xffffff/2 ))`; do echo “doop” | ncat <targetIP> <VNCPort>; done


2017-07-13 - Vendor Disclosure
2018-03-15 - Public Release


Discovered by Lilith <(-_-<) Wyatt of Cisco Talos