From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 842DC6A67 for ; Thu, 31 Mar 2016 13:21:19 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 31 Mar 2016 04:21:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,422,1455004800"; d="scan'208";a="678535455" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by FMSMGA003.fm.intel.com with ESMTP; 31 Mar 2016 04:21:16 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by irsmsx110.ger.corp.intel.com ([169.254.15.10]) with mapi id 14.03.0248.002; Thu, 31 Mar 2016 12:21:15 +0100 From: "Dumitrescu, Cristian" To: Robert Sanford , "dev@dpdk.org" Thread-Topic: [PATCH 2/4] port: fix ring writer buffer overflow Thread-Index: AQHRiTO66uY2w74KHkimCX1fioHDJZ9zYfeQ Date: Thu, 31 Mar 2016 11:21:15 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912647974D9C@IRSMSX108.ger.corp.intel.com> References: <1459198297-49854-1-git-send-email-rsanford@akamai.com> <1459198297-49854-3-git-send-email-rsanford@akamai.com> In-Reply-To: <1459198297-49854-3-git-send-email-rsanford@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzQxZGE5YjItMjQzZC00YzFiLThkMjEtNjMzMWFiOGJjZWJhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkZHRUVzb3VqaTFKR3htd1BJYWwxOXhqZ1kxaFk4ZXp3UVI3TjlYNHVIOEk9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/4] port: fix ring writer buffer overflow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 11:21:20 -0000 > -----Original Message----- > From: Robert Sanford [mailto:rsanford2@gmail.com] > Sent: Monday, March 28, 2016 9:52 PM > To: dev@dpdk.org; Dumitrescu, Cristian > Subject: [PATCH 2/4] port: fix ring writer buffer overflow >=20 > Ring writer tx_bulk functions may write past the end of tx_buf[]. > Solution is to double the size of tx_buf[]. >=20 > Signed-off-by: Robert Sanford > --- > lib/librte_port/rte_port_ring.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_r= ing.c > index b847fea..765ecc5 100644 > --- a/lib/librte_port/rte_port_ring.c > +++ b/lib/librte_port/rte_port_ring.c > @@ -179,7 +179,7 @@ rte_port_ring_reader_stats_read(void *port, > struct rte_port_ring_writer { > struct rte_port_out_stats stats; >=20 > - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX]; > + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; > struct rte_ring *ring; > uint32_t tx_burst_sz; > uint32_t tx_buf_count; > @@ -447,7 +447,7 @@ rte_port_ring_writer_stats_read(void *port, > struct rte_port_ring_writer_nodrop { > struct rte_port_out_stats stats; >=20 > - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX]; > + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; > struct rte_ring *ring; > uint32_t tx_burst_sz; > uint32_t tx_buf_count; > -- > 1.7.1 Hi Robert, How is the buffer overflow taking place? After looking long and hard, I spotted that buffer overflow can potentially= take place when the following conditions are met: 1. The input packet burst does not meet the conditions of (a) being contigu= ous (first n bits set in pkts_mask, all the other bits cleared) and (b) con= taining a full burst, i.e. at least tx_burst_sz packets (n >=3D tx_burst_si= ze). This is the slow(er) code path taken when local variable expr !=3D 0. 2. There are some packets already in the buffer. 3. The number of packets in the incoming burst (i.e. popcount(pkts_mask)) p= lus the number of packets already in the buffer exceeds the buffer size (RT= E_PORT_IN_BURST_SIZE_MAX, i.e. 64). Is this the buffer overflow scenario that you detected? Thanks, Cristian