qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vladislav Yasevich <vyasevic@redhat.com>
To: qemu-devel@nongnu.org
Cc: Vladislav Yasevich <vyasevic@redhat.com>,
	jasowang@redhat.com, stefanha@redhat.com
Subject: [Qemu-devel] [PATCH v4 0/2] rtl8139: Fix buffer overflow in standard mode
Date: Tue,  1 Sep 2015 11:26:44 -0400	[thread overview]
Message-ID: <1441121206-6997-1-git-send-email-vyasevic@redhat.com> (raw)

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

             reply	other threads:[~2015-09-01 15:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 15:26 Vladislav Yasevich [this message]
2015-09-01 15:26 ` [Qemu-devel] [PATCH v4 1/2] rtl8139: Fix receive buffer overflow check Vladislav Yasevich
2015-09-02  3:09   ` Jason Wang
2015-09-01 15:26 ` [Qemu-devel] [PATCH v4 2/2] rtl8139: Do not consume the packet during overflow in standard mode Vladislav Yasevich
2015-09-02  3:09   ` Jason Wang
2015-09-02 12:42 ` [Qemu-devel] [PATCH v4 0/2] rtl8139: Fix buffer " Stefan Hajnoczi
2015-09-02 12:53 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1441121206-6997-1-git-send-email-vyasevic@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).