From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id D6781A0352;
Thu, 16 Jan 2020 11:44:41 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 6AE681C1E6;
Thu, 16 Jan 2020 11:44:41 +0100 (CET)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com
[205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 14D8B1C1E5
for <dev@dpdk.org>; Thu, 16 Jan 2020 11:44:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1579171479;
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;
bh=gVMp1Cyrjh/nJk4Qy2iMqZOTqNhiKLlMcSHvzHtVg3I=;
b=fYTX1wrz8r+pYh5jEDTtIyc+vxX0Pd8nTPLSARDwvt14sn97D6POOJdyK97d8nIcnD1y9O
2EkN0yZHzcp7DbO4Vlli01otSdFb6P8+gmScNiSLUxb/1R+KHnP6jZ36Av7IVQ0Y71qm+2
c0L9E3bvSqtwoSNOG5xRNl+5pz2Gz3Q=
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-280-byhxRn2HNPKYIJJ5fkN9_A-1; Thu, 16 Jan 2020 05:44:38 -0500
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com
[10.5.11.23])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DB5C61800D48;
Thu, 16 Jan 2020 10:44:36 +0000 (UTC)
Received: from localhost.localdomain (unknown [10.36.112.13])
by smtp.corp.redhat.com (Postfix) with ESMTP id 10AE919C5B;
Thu, 16 Jan 2020 10:44:32 +0000 (UTC)
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: dev@dpdk.org,
tiwei.bie@intel.com,
zhihong.wang@intel.com
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>, stable@dpdk.org,
Ilja Van Sprundel <ivansprundel@ioactive.com>
Date: Thu, 16 Jan 2020 11:44:27 +0100
Message-Id: <20200116104427.3810-1-maxime.coquelin@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-MC-Unique: byhxRn2HNPKYIJJ5fkN9_A-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Subject: [dpdk-dev] [PATCH] vhost: catch overflow causing mmap of size 0
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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>
This patch catches an overflow that could happen if an
invalid region size or page alignement is provided by the
guest via the VHOST_USER_SET_MEM_TABLE request.
If the sum of the size to mmap and the alignment overflows
uint64_t, then RTE_ALIGN_CEIL(mmap_size, alignment) macro
will return 0. This value was passed as is as size argument
to mmap().
While kernel handling of mmap() syscall returns an error
if size is 0, it is better to catch it earlier and provide
a meaningful error log.
Fixes: ec09c280b839 ("vhost: fix mmap not aligned with hugepage size")
Cc: stable@dpdk.org
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost_user.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 0b7d1e288e..41ec069cb6 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -1145,6 +1145,21 @@ vhost_user_set_mem_table(struct virtio_net **pdev, s=
truct VhostUserMsg *msg,
=09=09=09goto err_mmap;
=09=09}
=09=09mmap_size =3D RTE_ALIGN_CEIL(mmap_size, alignment);
+=09=09if (mmap_size =3D=3D 0) {
+=09=09=09/*
+=09=09=09 * It could happen if initial mmap_size + alignment
+=09=09=09 * overflows the sizeof uint64, which could happen if
+=09=09=09 * either mmap_size or alignment value is wrong.
+=09=09=09 *
+=09=09=09 * mmap() kernel implementation would return an error,
+=09=09=09 * but better catch it before and provide useful info
+=09=09=09 * in the logs.
+=09=09=09 */
+=09=09=09VHOST_LOG_CONFIG(ERR, "mmap size (0x%" PRIx64 ") "
+=09=09=09=09=09"or alignment (0x%" PRIx64 ") is invalid\n",
+=09=09=09=09=09reg->size + mmap_offset, alignment);
+=09=09=09goto err_mmap;
+=09=09}
=20
=09=09populate =3D (dev->dequeue_zero_copy) ? MAP_POPULATE : 0;
=09=09mmap_addr =3D mmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
--=20
2.21.0