From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 19F29A0A02;
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 84C574067B;
Wed, 24 Mar 2021 09:56:05 +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 5611E4014F
for <dev@dpdk.org>; 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 <yong.liu@intel.com>, chenbo.xia@intel.com
Cc: dev@dpdk.org, stable@dpdk.org
References: <20210226073321.66996-1-yong.liu@intel.com>
From: Maxime Coquelin <maxime.coquelin@redhat.com>
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-dev] [PATCH] vhost: fix potential buffer overflow
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <yong.liu@intel.com>
> 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 <maxime.coquelin@redhat.com>
Thanks,
Maxime