|=----------------------------------------------------------------------------=|
|=-----------------------=[ Vulnerability Disclosure ]=-----------------------=|
|=-------=[ QEMU/Slirp: OOB access while processing ARP/NCSI packets ]=-------=|
|=----------------------------------------------------------------------------=|
|=-----------------------=[ Sun 11 Oct 2020 16:31:11 ]=-----------------------=|
|=-------------=[ https://qiuhao.org/VD_QEMU_Slirp_CWE-125.txt ]=-------------=|
|=----------------------------------------------------------------------------=|

In QEMU, User Networking is the default networking backend. It is implemented
using "slirp", which provides a full TCP/IP stack within QEMU and uses that
stack to implement a virtual NAT'd network.

During fuzzing, I find that slirp/src/slirp.c:slirp_input() makes sure the
pkt_len >= ETH_HLEN but doesn't check if it can hold the payload in
src/slirp.c:arp_input() and src/ncsi.c:ncsi_input(), which may leads to
out of bounds read (CWE-125):

void ncsi_input(Slirp *slirp, const uint8_t *pkt, int pkt_len)
{
    const struct ncsi_pkt_hdr *nh =
        (const struct ncsi_pkt_hdr *)(pkt + ETH_HLEN);

    // ... without checking pkt_len >= ETH_HLEN+len(shortest payload)
    // dereference nh and store data in the packet to send


static void arp_input(Slirp *slirp, const uint8_t *pkt, int pkt_len)
{
    const struct slirp_arphdr *ah =
        (const struct slirp_arphdr *)(pkt + ETH_HLEN);

    // ... without checking pkt_len >= ETH_HLEN+len(shortest payload)
    // dereference ah and store data in the packet to send

So attackers may first disable the automatic padding feature of a network
adapter (e.g., bit 11 of CSR4 for PCnet-PCI II) and send constructed Ethernet
packets (e.g., using raw sockets) to read sensitive information on the heap.

Update, Fri, 27 Nov 2020 18:38:05 +0530 (IST):
  CVE ID and Patch - https://www.openwall.com/lists/oss-security/2020/11/27/1