From mboxrd@z Thu Jan  1 00:00:00 1970
From: Amos Kong <akong@redhat.com>
Subject: Re: [PATCH 2/3] virtio: Strictly check queue_size when adding
 virtqueue
Date: Thu, 16 Jun 2011 06:53:59 +0800
Message-ID: <20110615225359.GA2354@t400>
References: <20110615142524.26726.13785.stgit@localhost6.localdomain6>
 <20110615142533.26726.54603.stgit@localhost6.localdomain6>
 <20110615203602.GB8362@redhat.com>
Reply-To: Amos Kong <akong@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org
To: "Michael S. Tsirkin" <mst@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:36143 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753728Ab1FOWyF (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 15 Jun 2011 18:54:05 -0400
Content-Disposition: inline
In-Reply-To: <20110615203602.GB8362@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Jun 15, 2011 at 11:36:02PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 15, 2011 at 10:25:33PM +0800, Amos Kong wrote:
> > Qemu should abort when 'queue_size' is less than or equals to zero.
> > 
> > Signed-off-by: Amos Kong <akong@redhat.com>
> 
> BTW, these patches apply upstream so should be sent to qemu-devel.
> 
> > ---
> >  hw/virtio.c |    3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/hw/virtio.c b/hw/virtio.c
> > index a3d0eee..855fe54 100644
> > --- a/hw/virtio.c
> > +++ b/hw/virtio.c
> > @@ -612,7 +612,8 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int queue_size,
> >              break;
> >      }
> >  
> > -    if (i == VIRTIO_PCI_QUEUE_MAX || queue_size > VIRTQUEUE_MAX_SIZE)
> > +    if (i == VIRTIO_PCI_QUEUE_MAX || queue_size > VIRTQUEUE_MAX_SIZE ||
> > +        queue_size <= 0)
> >          abort();
> >  
> >      vdev->vq[i].vring.num = queue_size;
> 
> These checks are just a debugging aid - there's no way
> for the guest or user to trigger this.
> I guess it does no harm, but what are we guarding against?
> Why would anyone pass in a negative value?

It seems all exist usage of this function are all right, guest/user could not trigger this right now.
So we don't need to fix this kind of problem?