CVE-2022-2962: High severity qemu vulnerability

When tulip reads or writes to the rx/tx descriptor or copies the rx/tx frame, it doesn't check whether the destination address is its own MMIO address. So crafted content can cause the device to trigger MMIO handlers again to modify some global variables and cause stack or heap overflow.

-- [ QEMU command line:

./qemu-system-x8664 -machine type=q35,accel=qtest -nodefaults -device tulip -qtest stdio -nographic

-- [ POC:

outl 0xcf8 0x80000804 / PCICMD—PCI Command Register / outl 0xcfc 0x107 / Enables accesses/ outl 0xcf8 0x80000814 / Memory Bar 1/ outl 0xcfc 0xfebf1000 / Set MMIO Address to 0xfebf1000/ writel 0xfebf1000 0 / tulipreset / writel 0xfebf1030 0x2001 / set csr6 flags CSR6ST|CSR6SR / writel 0xfebf1020 0xfebf1008 / set currenttxdesc to its MMIO address,and trigger tulipdescwrite /

-- [ Analysis

(1) setting s->currentrxdesc to tulip MMIO address + CSR(1). (2) Then tulipxmitlistupdate was executed, and tulipdescwrite wrote a descriptor to its MMIO address+CSR(1). (3) Tulipxmitlistupdate was called again. Then，(2)(3) was executed thousands of times until the stack overflowed.

I found that the same problem could occur in tulipreceive (it can be called by mmio write) and may cause heap overflow: (1) In tulipcopyrxbytes set s->currentrxdesc to its mmio address + CSR(1) via pcidmawrite, then s->rxframelen is set to 0. (2) When tulipdescwrite executes, another tulipreceive is called, s->rxframelen can be set to a big value. (3) But the first tulipreceive does not end,and s->rxframelen is bigger than s->rxframesize, so tulipcopyrxbytes causes heap overflow.

-- [ Reporter Siqi Chen (Shanghai Jiaotong University)

— Red Hat