From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id E62F32E8F for ; Thu, 10 Mar 2016 05:30:14 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 09 Mar 2016 20:30:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,314,1455004800"; d="scan'208";a="920667212" Received: from yliu-dev.sh.intel.com ([10.239.66.49]) by fmsmga001.fm.intel.com with ESMTP; 09 Mar 2016 20:30:13 -0800 From: Yuanhan Liu To: dev@dpdk.org Date: Thu, 10 Mar 2016 12:32:44 +0800 Message-Id: <1457584366-3036-7-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1457584366-3036-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1455803352-5518-1-git-send-email-yuanhan.liu@linux.intel.com> <1457584366-3036-1-git-send-email-yuanhan.liu@linux.intel.com> Subject: [dpdk-dev] [PATCH v3 6/8] 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, 10 Mar 2016 04:30:15 -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 available. 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 50f449f..86e4d1a 100644 --- a/lib/librte_vhost/vhost_rxtx.c +++ b/lib/librte_vhost/vhost_rxtx.c @@ -151,6 +151,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); @@ -448,6 +451,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); @@ -737,6 +743,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 -1; + desc_addr = gpa_to_vva(dev, desc->addr); rte_prefetch0((void *)(uintptr_t)desc_addr); -- 1.9.0