Heap overflow in QEMU PCNET controller, allowing guest->host escape

ISSUE DESCRIPTION

The QEMU security team has predisclosed the following advisory:
pcnet_transmit loads a transmit-frame descriptor from the guest into the /tmd/ local variable to recover a length field, a status field and a guest-physical location of the associated frame buffer. If the status field indicates that the frame buffer is ready to be sent out (i.e. by setting the TXSTATUS_DEVICEOWNS, TXSTATUS_STARTPACKET and TXSTATUS_ENDPACKET bits on the status field), the PCNET device controller pulls in the frame from the guest-physical location to s->buffer (which is 4096 bytes long), and then transmits the frame.
Because of the layout of the transmit-frame descriptor, it is not possible to send the PCNET device controller a frame of length > 4096, but it /is/ possible to send the PCNET device controller a frame that is marked as TXSTATUS_STARTPACKET, but not TXSTATUS_ENDPACKET. If we do this - and the PCNET controller is configured via the XMTRL CSR to support split-frame processing - then the pcnet_transmit functions loops round, pulling a second transmit frame descriptor from the guest. If this second transmit frame descriptor sets the TXSTATUS_DEVICEOWNS and doesn’t set the TXSTATUS_STARTPACKET bits, this frame is appended to the s->buffer field.
An attacker can then exploit this vulnerability by sending a first packet of length 4096 to the device controller, and a second frame containing N-bytes to trigger an N-byte heap overflow.
On 64-bit QEMU, a 24-byte overflow allows the guest to take control of the phys_mem_write function pointer in the PCNetState_st structure, and this is called when trying to flush the updated transmit frame descriptor back to the guest. By specifying the content of the second transmit frame, the attacker therefore gets reliable fully-chosen control of the host instruction pointer, allowing them to take control of the host.

IMPACT

A guest which has access to an emulated PCNET network device (e.g. with “model=pcnet” in their VIF configuration) can exploit this vulnerability to take over the qemu process elevating its privilege to that of the qemu process.

VULNERABLE SYSTEMS

All Xen systems running x86 HVM guests without stubdomains which have been configured to use the PCNET emulated driver model are vulnerable.
The default configuration is NOT vulnerable (because it does not emulate PCNET NICs).
Systems running only PV guests are NOT vulnerable.
Systems using qemu-dm stubdomain device models (for example, by specifying “device_model_stubdomain_override=1” in xl’s domain configuration files) are NOT vulnerable.
Both the traditional “qemu-xen” or upstream qemu device models are potentially vulnerable.
ARM systems are NOT vulnerable.