From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D3228A0096 for ; Wed, 8 May 2019 18:03:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CA9434C94; Wed, 8 May 2019 18:03:23 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id C2D634C94 for ; Wed, 8 May 2019 18:03:22 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 313C8307B964; Wed, 8 May 2019 16:03:22 +0000 (UTC) Received: from rh.redhat.com (ovpn-117-210.ams2.redhat.com [10.36.117.210]) by smtp.corp.redhat.com (Postfix) with ESMTP id E38C160C82; Wed, 8 May 2019 16:03:20 +0000 (UTC) From: Kevin Traynor To: Herakliusz Lipiec Cc: Anatoly Burakov , Ferruh Yigit , dpdk stable Date: Wed, 8 May 2019 17:02:27 +0100 Message-Id: <20190508160233.2648-30-ktraynor@redhat.com> In-Reply-To: <20190508160233.2648-1-ktraynor@redhat.com> References: <20190508160233.2648-1-ktraynor@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Wed, 08 May 2019 16:03:22 +0000 (UTC) Subject: [dpdk-stable] patch 'net/tap: fix potential IPC buffer overrun' has been queued to LTS release 18.11.2 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 LTS release 18.11.2 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/14/19. 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. Queued patches are on a temporary branch at: https://github.com/kevintraynor/dpdk-stable-queue This queued commit can be viewed at: https://github.com/kevintraynor/dpdk-stable-queue/commit/4a13ffc0ad2b086ff8c4bd60e0d5315380487e1d Thanks. Kevin Traynor --- >From 4a13ffc0ad2b086ff8c4bd60e0d5315380487e1d Mon Sep 17 00:00:00 2001 From: Herakliusz Lipiec Date: Mon, 29 Apr 2019 18:31:21 +0100 Subject: [PATCH] net/tap: fix potential IPC buffer overrun [ upstream commit 9ad43ad8fbeeec1a485233227da21fd71e175984 ] When secondary to primary process synchronization occurs there is no check for number of fds which could cause buffer overrun. Bugzilla ID: 252 Fixes: c9aa56edec8e ("net/tap: access primary process queues from secondary") Signed-off-by: Herakliusz Lipiec Reviewed-by: Anatoly Burakov Reviewed-by: Ferruh Yigit --- drivers/net/tap/rte_eth_tap.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c index 292657d0b..867873683 100644 --- a/drivers/net/tap/rte_eth_tap.c +++ b/drivers/net/tap/rte_eth_tap.c @@ -2082,4 +2082,9 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev) /* Attach the queues from received file descriptors */ + if (reply_param->rxq_count + reply_param->txq_count != reply->num_fds) { + TAP_LOG(ERR, "Unexpected number of fds received"); + return -1; + } + dev->data->nb_rx_queues = reply_param->rxq_count; dev->data->nb_tx_queues = reply_param->txq_count; @@ -2122,4 +2127,10 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) reply.num_fds = 0; reply_param->rxq_count = 0; + if (dev->data->nb_rx_queues + dev->data->nb_tx_queues > + RTE_MP_MAX_FD_NUM){ + TAP_LOG(ERR, "Number of rx/tx queues exceeds max number of fds"); + return -1; + } + for (queue = 0; queue < dev->data->nb_rx_queues; queue++) { reply.fds[reply.num_fds++] = process_private->rxq_fds[queue]; @@ -2127,6 +2138,4 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) } RTE_ASSERT(reply_param->rxq_count == dev->data->nb_rx_queues); - RTE_ASSERT(reply_param->txq_count == dev->data->nb_tx_queues); - RTE_ASSERT(reply.num_fds <= RTE_MP_MAX_FD_NUM); reply_param->txq_count = 0; @@ -2135,4 +2144,5 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) reply_param->txq_count++; } + RTE_ASSERT(reply_param->txq_count == dev->data->nb_tx_queues); /* Send reply */ -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2019-05-08 16:33:58.987671919 +0100 +++ 0030-net-tap-fix-potential-IPC-buffer-overrun.patch 2019-05-08 16:33:57.444577142 +0100 @@ -1 +1 @@ -From 9ad43ad8fbeeec1a485233227da21fd71e175984 Mon Sep 17 00:00:00 2001 +From 4a13ffc0ad2b086ff8c4bd60e0d5315380487e1d Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit 9ad43ad8fbeeec1a485233227da21fd71e175984 ] + @@ -11 +12,0 @@ -Cc: stable@dpdk.org @@ -21 +22 @@ -index f8a4169c5..47a2b68f1 100644 +index 292657d0b..867873683 100644 @@ -24 +25 @@ -@@ -2112,4 +2112,9 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev) +@@ -2082,4 +2082,9 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev) @@ -34 +35 @@ -@@ -2152,4 +2157,10 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) +@@ -2122,4 +2127,10 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) @@ -45 +46 @@ -@@ -2157,6 +2168,4 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) +@@ -2127,6 +2138,4 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) @@ -52 +53 @@ -@@ -2165,4 +2174,5 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer) +@@ -2135,4 +2144,5 @@ tap_mp_sync_queues(const struct rte_mp_msg *request, const void *peer)