From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 3A03E8002 for ; Mon, 27 Oct 2014 10:05:55 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XigQc-0000XU-9H; Mon, 27 Oct 2014 10:17:33 +0100 Message-ID: <544E0CF2.8090408@6wind.com> Date: Mon, 27 Oct 2014 10:14:26 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Carew, Alan" , "dev@dpdk.org" References: <1413818593-26269-1-git-send-email-alan.carew@intel.com> <0E29434AEE0C3A4180987AB476A6F6306D281C01@IRSMSX109.ger.corp.intel.com> In-Reply-To: <0E29434AEE0C3A4180987AB476A6F6306D281C01@IRSMSX109.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] librte_cmdline: FreeBSD Fix oveflow when size of command result structure is greater than BUFSIZ 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: Mon, 27 Oct 2014 09:05:55 -0000 Hello Alan, On 10/20/2014 05:26 PM, Carew, Alan wrote: > A comment on my own patch. > > Making the size of result_buf consistent across each OS and keeping it as large > as the Linux BUFSIZ(8192) doesn't really address the core issue. > > In the event that a user of librte_cmdline creates a custom context with a > result structure > 8192 bytes then this problem will occur again, though > somewhat unlikely, as the minimum number of the largest type would be 64 x > cmdline_fixed_string_t types within a result structure, at its current size. > > There is no checking of overflow, I would be tempted to add a runtime check in > cmdline_parse()/match_inst(), however I would be more comfortable with a build > time check for this type of problem. > > Due to the opaque handling of user defined contexts there is no obvious way to > do this at build time. > > Thoughts? Indeed, your patch does not address the core issue of the problem, altough it's already an improvement to the current situation. Your issue was already fixed in the latest libcmdline library by this patch (which also includes the replacement of BUFSIZ): http://git.droids-corp.org/?p=libcmdline.git;a=commitdiff;h=b1d5b169352e57df3fc14c51ffad4b83f3e5613f I'm pretty sure it won't apply smoothly on the dpdk command line library but it can probably be adapted. Ideally, the latest libcmdline library should be [cleaned first and] merged in dpdk.org. Regards, Olivier