qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Fleytman <dmitry.fleytman@gmail.com>
To: Alexander Bulekov <alxndr@bu.edu>
Cc: Jason Wang <jasowang@redhat.com>,
	Mauro Matteo Cascella <mcascell@redhat.com>,
	qemu-devel@nongnu.org, ezrakiez@gmail.com
Subject: Re: [PATCH 0/2] assertion failure in net_tx_pkt_add_raw_fragment() in hw/net/net_tx_pkt.c
Date: Wed, 29 Jul 2020 11:48:08 +0300	[thread overview]
Message-ID: <AA604F63-C36B-471C-9E0C-F9A84C9595BA@gmail.com> (raw)
In-Reply-To: <20200727172929.5nnasrbvp2gg3yyv@mozz.bu.edu>

Reviewed-by: Dmitry Fleytman <dmitry.fleytman@gmail.com>

The idea looks good to me. I believe it makes sense to do the check in net_tx_pkt_add_raw_fragment() as suggested by Jason.

> On 27 Jul 2020, at 20:29, Alexander Bulekov <alxndr@bu.edu> wrote:
> 
> I sent a reproducer for the to the list some time ago, but never created
> a Launchpad bug...
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg701930.html
> 
> Anyways.. I can confirm that I can't reproduce the issue with these
> patches.
> 
> Minimized Reproducer:
> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -nographic \
> -display none -serial none -monitor none -qtest stdio
> outl 0xcf8 0x80001010
> outl 0xcfc 0xe1020000
> outl 0xcf8 0x80001004
> outw 0xcfc 0x7
> write 0xe10207e8 0x4 0x25ff13ff
> write 0xe10200b8 0x7 0xe3055e411b0202
> write 0xe1020100 0x5 0x5e411b0202
> write 0xe1020110 0x4 0x1b0202e1
> write 0xe1020118 0x4 0x06fff105
> write 0xe1020128 0x7 0xf3055e411b0202
> write 0xe1020402 0x2 0x5e41
> write 0xe1020420 0x4 0x1b0202e1
> write 0xe1020428 0x4 0x06ff6105
> write 0xe1020438 0x1 0x63
> write 0xe1020439 0x1 0x05
> EOF
> 
> -Alex
> 
> On 200727 1908, Mauro Matteo Cascella wrote:
>> An assertion failure issue was reported by Mr. Ziming Zhang (CC'd).
>> It occurs in the code that processes network packets while adding data
>> fragments into packet context. This flaw could potentially be abused by
>> a malicious guest to abort the QEMU process on the host. This two patch
>> series does a couple of things:
>> 
>> - introduces a new function in net_tx_pkt.{c,h} to check the maximum number
>>  of data fragments
>> - adds a check in both e1000e and vmxnet3 devices to skip the packet if the
>>  current data fragment exceeds max_raw_frags, preventing
>>  net_tx_pkt_add_raw_fragment() to be called with an invalid raw_frags
>> 
>> Mauro Matteo Cascella (2):
>>  hw/net/net_tx_pkt: add function to check pkt->max_raw_frags
>>  hw/net: check max_raw_frags in e1000e and vmxnet3 devices
>> 
>> hw/net/e1000e_core.c | 3 ++-
>> hw/net/net_tx_pkt.c  | 5 +++++
>> hw/net/net_tx_pkt.h  | 8 ++++++++
>> hw/net/vmxnet3.c     | 3 ++-
>> 4 files changed, 17 insertions(+), 2 deletions(-)
>> 
>> -- 
>> 2.26.2
>> 
>> 



      parent reply	other threads:[~2020-07-29  8:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 17:08 [PATCH 0/2] assertion failure in net_tx_pkt_add_raw_fragment() in hw/net/net_tx_pkt.c Mauro Matteo Cascella
2020-07-27 17:08 ` [PATCH 1/2] hw/net/net_tx_pkt: add function to check pkt->max_raw_frags Mauro Matteo Cascella
2020-07-28  4:06   ` Jason Wang
2020-07-28 16:26     ` Mauro Matteo Cascella
2020-07-30  5:27       ` Jason Wang
2020-07-30 17:05         ` Mauro Matteo Cascella
2020-07-31  3:33           ` Jason Wang
2020-07-27 17:08 ` [PATCH 2/2] hw/net: check max_raw_frags in e1000e and vmxnet3 devices Mauro Matteo Cascella
2020-07-27 17:29 ` [PATCH 0/2] assertion failure in net_tx_pkt_add_raw_fragment() in hw/net/net_tx_pkt.c Alexander Bulekov
2020-07-28 16:59   ` Mauro Matteo Cascella
2020-07-29  8:48   ` Dmitry Fleytman [this message]

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=AA604F63-C36B-471C-9E0C-F9A84C9595BA@gmail.com \
    --to=dmitry.fleytman@gmail.com \
    --cc=alxndr@bu.edu \
    --cc=ezrakiez@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=mcascell@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).