From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnSW-0004GN-MT for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:26:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWnST-0007lx-UZ for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:26:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnST-0007lj-Ow for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:26:49 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 1A1B4550CC for ; Tue, 1 Sep 2015 15:26:49 +0000 (UTC) From: Vladislav Yasevich Date: Tue, 1 Sep 2015 11:26:44 -0400 Message-Id: <1441121206-6997-1-git-send-email-vyasevic@redhat.com> Subject: [Qemu-devel] [PATCH v4 0/2] rtl8139: Fix buffer overflow in standard mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Vladislav Yasevich , jasowang@redhat.com, stefanha@redhat.com When rtl8139 card is running in standard mode, it is very easy to overlflow and the receive buffer and get into a siutation where all packets are dropped. Simply reproduction case is to ping the guest from the host with 6500 byte packets. There are actually 2 problems here. 1) When the rtl8129 buffer is overflow, the card emulation returns the size of the packet back to queue transmission. This signals successful reception even though the packet has been dropped. The proper solution is to return 0, so that the packet is re-queued and will be resubmitted later. 2) The RxBuffAddr pointer used to track where packet is to be written is aligned on a 4 byte boundary thus potentially adding some padding between packets. This padding is ignored when checking for overflow condition. It is possible to craft the packet such that we would fail to detect an overflow and trigger buffer overwrite. Adding padding to the overflow check resolves this issues. V4: As Jason Wang correctly pointed out, the overflow check should catch this. The reason it wasn't catching was that it was ignorring the padding that may exist between each packet. Adding the padding to the overflow check resolved the issue. This becomes a much simpler fix. V3: Fix the second patch to correctly track unread and available buffer speace. Prior version used calculation for availble space to track unread space which was wrong. V2: instead of tracking buffer_full condition, changed the code, as suggested by Stefan Hajnoczi, to track the number of unread bytes instead. We initialize it to 0 at the start, adjust it on every receive from the network and read from the guest and can set the number of unread of bytes to full buffer size when the buffer full. Vladislav Yasevich (2): rtl8139: Fix receive buffer overflow check rtl8139: Do not consume the packet during overflow in standard mode. hw/net/rtl8139.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 1.9.3