From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 79004C3A4 for ; Thu, 18 Feb 2016 14:48:53 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 18 Feb 2016 05:48:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,465,1449561600"; d="scan'208";a="655017164" Received: from yliu-dev.sh.intel.com ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 18 Feb 2016 05:48:52 -0800 From: Yuanhan Liu To: dev@dpdk.org Date: Thu, 18 Feb 2016 21:49:11 +0800 Message-Id: <1455803352-5518-7-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1455803352-5518-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com> <1455803352-5518-1-git-send-email-yuanhan.liu@linux.intel.com> Cc: "Michael S. Tsirkin" , Victor Kaplansky Subject: [dpdk-dev] [PATCH v2 6/7] vhost: do sanity check for desc->len X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:48:53 -0000 We need make sure that desc->len is bigger than the size of virtio net header, otherwise, unexpected behaviour might happen due to "desc_avail" would become a huge number with for following code: desc_avail = desc->len - vq->vhost_hlen; For dequeue code path, it will try to allocate enough mbuf to hold such size of desc buf, which ends up with consuming all mbufs, leading to no free mbuf is avaliable. Therefore, you might see an error message: Failed to allocate memory for mbuf. Also, for both dequeue/enqueue code path, while it copies data from/to desc buf, the big "desc_avail" would result to access memory not belong the desc buf, which could lead to some potential memory access errors. A malicious guest could easily forge such malformed vring desc buf. Every time we restart an interrupted DPDK application inside guest would also trigger this issue, as all huge pages are reset to 0 during DPDK re-init, leading to desc->len being 0. Therefore, this patch does a sanity check for desc->len, to make vhost robust. Reported-by: Rich Lane Signed-off-by: Yuanhan Liu --- lib/librte_vhost/vhost_rxtx.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c index 04af9b3..c2adcd9 100644 --- a/lib/librte_vhost/vhost_rxtx.c +++ b/lib/librte_vhost/vhost_rxtx.c @@ -115,6 +115,9 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct vhost_virtqueue *vq, struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0}; desc = &vq->desc[desc_idx]; + if (unlikely(desc->len < vq->vhost_hlen)) + return -1; + desc_addr = gpa_to_vva(dev, desc->addr); rte_prefetch0((void *)(uintptr_t)desc_addr); @@ -406,6 +409,9 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq, "(%"PRIu64") Current Index %d| End Index %d\n", dev->device_fh, cur_idx, res_end_idx); + if (vq->buf_vec[vec_idx].buf_len < vq->vhost_hlen) + return -1; + desc_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr); rte_prefetch0((void *)(uintptr_t)desc_addr); @@ -649,6 +655,9 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vhost_virtqueue *vq, struct virtio_net_hdr *hdr; desc = &vq->desc[desc_idx]; + if (unlikely(desc->len < vq->vhost_hlen)) + return NULL; + desc_addr = gpa_to_vva(dev, desc->addr); rte_prefetch0((void *)(uintptr_t)desc_addr); -- 1.9.0