From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A14ADA0A0A for ; Wed, 24 Mar 2021 09:56:06 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 897B9140D03; Wed, 24 Mar 2021 09:56:06 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 5AFEA4067B for ; Wed, 24 Mar 2021 09:56:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616576163; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/MpozKhztwUzV+Xm7owoWMNW4itwkZ5LRshl71ybY2U=; b=URxooUhUNpbwJGto4VDcZdaTLcf07p7fLL1jtbw1ULtCzRKrs50+XyLwNmUeTX3aJPoIOz AMqA1tVJD2tkJg5lmvUB8L+EVUXzBXdPbKirUN76TmLtDFaOMOF2wm4Gg0enjGbNtL01g2 VB3xBzCN1cHR8aLq5RxYX75E83+syX0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-328-PcSQvv6SPhi9taYNOcIRVg-1; Wed, 24 Mar 2021 04:56:01 -0400 X-MC-Unique: PcSQvv6SPhi9taYNOcIRVg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AFB4281627; Wed, 24 Mar 2021 08:56:00 +0000 (UTC) Received: from [10.36.110.41] (unknown [10.36.110.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E7BF2C8CD; Wed, 24 Mar 2021 08:55:59 +0000 (UTC) To: Marvin Liu , chenbo.xia@intel.com Cc: dev@dpdk.org, stable@dpdk.org References: <20210226073321.66996-1-yong.liu@intel.com> From: Maxime Coquelin Message-ID: <7daf5cb5-173f-ce38-b14e-5dc00fe970c8@redhat.com> Date: Wed, 24 Mar 2021 09:55:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210226073321.66996-1-yong.liu@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [PATCH] vhost: fix potential buffer overflow X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi Marvin, On 2/26/21 8:33 AM, Marvin Liu wrote: > In vhost datapath, descriptor's length are mostly used in two coherent > operations. First step is used for address translation, second step is > used for memory transaction from guest to host. But the iterval between > two steps will give a window for malicious guest, in which can change > descriptor length after vhost calcuated buffer size. Thus may lead to > buffer overflow in vhost side. This potential risk can be eliminated by > accessing the descriptor length once. > > Fixes: 1be4ebb1c464 ("vhost: support indirect descriptor in mergeable Rx") > Fixes: 2f3225a7d69b ("vhost: add vector filling support for packed ring") > Fixes: 75ed51697820 ("vhost: add packed ring batch dequeue") As the offending commits have been introduced in different LTS, I would prefer the patch to be split. It will make is easier for backporting later. > Signed-off-by: Marvin Liu > Cc: stable@dpdk.org > > diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c > index 583bf379c6..0a7d008a91 100644 > --- a/lib/librte_vhost/virtio_net.c > +++ b/lib/librte_vhost/virtio_net.c > @@ -548,10 +548,11 @@ fill_vec_buf_split(struct virtio_net *dev, struct vhost_virtqueue *vq, > return -1; > } > > - len += descs[idx].len; > + dlen = descs[idx].len; > + len += dlen; > > if (unlikely(map_one_desc(dev, vq, buf_vec, &vec_id, > - descs[idx].addr, descs[idx].len, > + descs[idx].addr, dlen, > perm))) { > free_ind_table(idesc); > return -1; > @@ -668,9 +669,10 @@ fill_vec_buf_packed_indirect(struct virtio_net *dev, > return -1; > } > > - *len += descs[i].len; > + dlen = descs[i].len; > + *len += dlen; > if (unlikely(map_one_desc(dev, vq, buf_vec, &vec_id, > - descs[i].addr, descs[i].len, > + descs[i].addr, dlen, > perm))) > return -1; > } > @@ -691,6 +693,7 @@ fill_vec_buf_packed(struct virtio_net *dev, struct vhost_virtqueue *vq, > bool wrap_counter = vq->avail_wrap_counter; > struct vring_packed_desc *descs = vq->desc_packed; > uint16_t vec_id = *vec_idx; > + uint64_t dlen; > > if (avail_idx < vq->last_avail_idx) > wrap_counter ^= 1; > @@ -723,11 +726,12 @@ fill_vec_buf_packed(struct virtio_net *dev, struct vhost_virtqueue *vq, > len, perm) < 0)) > return -1; > } else { > - *len += descs[avail_idx].len; > + dlen = descs[avail_idx].len; > + *len += dlen; > > if (unlikely(map_one_desc(dev, vq, buf_vec, &vec_id, > descs[avail_idx].addr, > - descs[avail_idx].len, > + dlen, > perm))) > return -1; > } > @@ -2314,7 +2318,7 @@ vhost_reserve_avail_batch_packed(struct virtio_net *dev, > } > > vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) { > - pkts[i]->pkt_len = descs[avail_idx + i].len - buf_offset; > + pkts[i]->pkt_len = lens[i] - buf_offset; > pkts[i]->data_len = pkts[i]->pkt_len; > ids[i] = descs[avail_idx + i].id; > } > Other than that, the patch looks valid to me. With the split done: Reviewed-by: Maxime Coquelin Thanks, Maxime