From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E52DFA051C for ; Tue, 11 Feb 2020 12:42:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7E3F71C012; Tue, 11 Feb 2020 12:42:34 +0100 (CET) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id A45EC1C0B6 for ; Tue, 11 Feb 2020 12:42:32 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id a6so3146564wme.2 for ; Tue, 11 Feb 2020 03:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2chRIcwPbNlRs+ctokSuraEIQsOc8PYSBFXjl0Kgt2A=; b=jJnIzGsef6gRxQpYnc8aY2bo6bhKIBe8+tVcSo8IVG4QmE+5/PYpauEpNeI7+evz81 jTHRKbv85Evd0APu+O4UA/QCewvK22PzGaPNa3Q+yRsZ6gfQUYnVyDlTP1qLByoFy4ZP SrM/ooVaxEEbhRXPaHL+4SnmWXZJKWCsPJX1DFJJxS3aLkzx9OqeXMYBUhNpu2JgE2Px faGfp/gwA+VfV/qU9KvjuhTRl/uEMD7r2hjyjcgsL4P/aFoOZ1MElz4feyp6dJ//FZb3 moPktGNWpUwpKMjzusL6jqFytrrstqpadhGy/vmGYEmG5iINajiq1lpCZM90mM4sJncn /uZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2chRIcwPbNlRs+ctokSuraEIQsOc8PYSBFXjl0Kgt2A=; b=nO9EuN350ewXRd4wMfOySY3yBLaFm8i7LdGmQKsf2VWChW0MGL2TIhEAXJPxVhENai U93TUePWv/Mh7hitmC9cS0jDZjGnPXuIcVMTq3NjHF83V9pI1aYFfJEKnGdgSwapDqUC Mlqu8imsf6oeb65YPQLlqpkFUp7h3eRD/inxKzgzA7VlC3ES9vM1P/cvqD/C8rLH5kRb 9NZQJrsEfNGHVJN23wi6nUN7o/AHm16nR3R4RN+PeYveNRMARAWPMrH50DQ/35+1wdeT LUJL8txPb8mU3n7GiUoshEwKE8O6afdUfKTwpzTdbk5h07wAcSVSErl7IXmf2MSqOx2t FbCA== X-Gm-Message-State: APjAAAXGbaZ4TxMkXRE1lqt4EPxLttbC+ZikBBzu8TLZOeChSqriqOTq 3N/p4F1n6aaxCNv+Jl/LGhQ= X-Google-Smtp-Source: APXvYqyrHOyMhmtDwwFFHKbRbrfv2pLHu4rcHcuwHPeWO/ObSutW6Y0PKZlkew/yJhbzk3DGXCTAlw== X-Received: by 2002:a1c:66d6:: with SMTP id a205mr5223074wmc.10.1581421352403; Tue, 11 Feb 2020 03:42:32 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id y20sm3285171wmi.25.2020.02.11.03.42.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 03:42:31 -0800 (PST) From: luca.boccassi@gmail.com To: Maxime Coquelin Cc: Ilja Van Sprundel , Tiwei Bie , dpdk stable Date: Tue, 11 Feb 2020 11:22:07 +0000 Message-Id: <20200211112216.3929-181-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200211112216.3929-1-luca.boccassi@gmail.com> References: <20200211112216.3929-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'vhost: catch overflow causing mmap of size 0' has been queued to stable release 19.11.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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, FYI, your patch has been queued to stable release 19.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/13/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From 43bbd5262003581cadec3b1068ffdb62a4bd3cb0 Mon Sep 17 00:00:00 2001 From: Maxime Coquelin Date: Thu, 16 Jan 2020 11:44:27 +0100 Subject: [PATCH] vhost: catch overflow causing mmap of size 0 [ upstream commit c6420a36328b9c6b71770aaa982abacd0e2440b8 ] This patch catches an overflow that could happen if an invalid region size or page alignment 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") Reported-by: Ilja Van Sprundel Signed-off-by: Maxime Coquelin Reviewed-by: Tiwei Bie --- 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 1c3a1a89fc..4312e5e536 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, struct VhostUserMsg *msg, goto err_mmap; } mmap_size = RTE_ALIGN_CEIL(mmap_size, alignment); + if (mmap_size == 0) { + /* + * It could happen if initial mmap_size + alignment + * overflows the sizeof uint64, which could happen if + * either mmap_size or alignment value is wrong. + * + * mmap() kernel implementation would return an error, + * but better catch it before and provide useful info + * in the logs. + */ + RTE_LOG(ERR, VHOST_CONFIG, "mmap size (0x%" PRIx64 ") " + "or alignment (0x%" PRIx64 ") is invalid\n", + reg->size + mmap_offset, alignment); + goto err_mmap; + } populate = (dev->dequeue_zero_copy) ? MAP_POPULATE : 0; mmap_addr = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-02-11 11:17:44.830085085 +0000 +++ 0181-vhost-catch-overflow-causing-mmap-of-size-0.patch 2020-02-11 11:17:38.832009425 +0000 @@ -1,8 +1,10 @@ -From c6420a36328b9c6b71770aaa982abacd0e2440b8 Mon Sep 17 00:00:00 2001 +From 43bbd5262003581cadec3b1068ffdb62a4bd3cb0 Mon Sep 17 00:00:00 2001 From: Maxime Coquelin Date: Thu, 16 Jan 2020 11:44:27 +0100 Subject: [PATCH] vhost: catch overflow causing mmap of size 0 +[ upstream commit c6420a36328b9c6b71770aaa982abacd0e2440b8 ] + This patch catches an overflow that could happen if an invalid region size or page alignment is provided by the guest via the VHOST_USER_SET_MEM_TABLE request. @@ -17,7 +19,6 @@ a meaningful error log. Fixes: ec09c280b839 ("vhost: fix mmap not aligned with hugepage size") -Cc: stable@dpdk.org Reported-by: Ilja Van Sprundel Signed-off-by: Maxime Coquelin @@ -27,7 +28,7 @@ 1 file changed, 15 insertions(+) diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c -index c9cc4d6489..9f14ea6676 100644 +index 1c3a1a89fc..4312e5e536 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, struct VhostUserMsg *msg, @@ -44,7 +45,7 @@ + * but better catch it before and provide useful info + * in the logs. + */ -+ VHOST_LOG_CONFIG(ERR, "mmap size (0x%" PRIx64 ") " ++ RTE_LOG(ERR, VHOST_CONFIG, "mmap size (0x%" PRIx64 ") " + "or alignment (0x%" PRIx64 ") is invalid\n", + reg->size + mmap_offset, alignment); + goto err_mmap;