From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL0Gv-00089y-00 for qemu-devel@nongnu.org; Sun, 17 Jan 2016 22:14:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL0Gu-0000FF-2s for qemu-devel@nongnu.org; Sun, 17 Jan 2016 22:14:24 -0500 References: <1452764448-17953-1-git-send-email-mst@redhat.com> From: Jason Wang Message-ID: <569C587B.3080505@redhat.com> Date: Mon, 18 Jan 2016 11:14:03 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH] cadence_gem: fix buffer overflow List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , Peter Maydell Cc: "Michael S. Tsirkin" , QEMU Developers , Prasad Pandit , qemu-arm , =?UTF-8?B?5YiY5Luk?= , Alistair Francis On 01/15/2016 02:19 PM, Peter Crosthwaite wrote: > On Thu, Jan 14, 2016 at 2:03 AM, Peter Maydell wrote: >> On 14 January 2016 at 09:43, Michael S. Tsirkin wrote= : >>> gem_receive copies a packet received from network into an rxbuf[2048] >>> array on stack, with size limited by descriptor length set by guest. = If >>> guest is malicious and specifies a descriptor length that is too larg= e, >>> and should packet size exceed array size, this results in a buffer >>> overflow. >>> >>> Reported-by: =E5=88=98=E4=BB=A4 >>> Signed-off-by: Michael S. Tsirkin >>> --- >>> hw/net/cadence_gem.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c >>> index 3639fc1..15a0786 100644 >>> --- a/hw/net/cadence_gem.c >>> +++ b/hw/net/cadence_gem.c >>> @@ -862,6 +862,14 @@ static void gem_transmit(CadenceGEMState *s) >>> break; >>> } >>> >>> + if (tx_desc_get_length(desc) > sizeof(tx_packet) - (p - tx_p= acket)) { >>> + DB_PRINT("TX descriptor @ 0x%x too large: size 0x%x spac= e 0x%x\n", >>> + (unsigned)packet_desc_addr, >>> + (unsigned)tx_desc_get_length(desc), >>> + sizeof(tx_packet) - (p - tx_packet)); >>> + break; >>> + } >> Is this what the real hardware does in this situation? >> Should we log this as a guest error? >> > I'm not sure it is a guest error. I think its just a shortcut in the > original implementation. I guess QEMU needs the whole packet before > handing off to the net layer and the assumption is that the packet is > always within 2048. I think the hardware is just going to put the data > on the wire as it goes. If we are not sure this is what real hardware did, dropping looks more safe than sending the truncated packets on the wire. > The easiest solution is to realloc the buffer > as it goes with the increasing sizes. This could allow possible DOS from guest (see cde31a0e3dc0e4ac83e454d6096350cec584adf1). > Otherwise you could refactor the > code to be two pass over the descriptor ring section (containing the > packet). If we want to fix the buffer overflow more urgently, the > correct error would be an assert(). > > Regards, > Peter Let's avoid putting guest trigger-able assert() here. The patch looks good for fixing the issue. Refactoring could be done on top. Thanks > >>> + >>> /* Gather this fragment of the packet from "dma memory" to o= ur contig. >>> * buffer. >>> */ >>> -- >>> MST >>> >> thanks >> -- PMM >>