From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id EADA97E89 for ; Mon, 20 Oct 2014 22:17:06 +0200 (CEST) Received: by mail-wi0-f177.google.com with SMTP id fb4so53908wid.4 for ; Mon, 20 Oct 2014 13:25:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=Lfz2UUEUUDmRJNWZ8OBiSvuEpMXO82dFqxQjb6YuQlI=; b=gar8J+P2yrfNHTYyTSeYu1g2QVJTWAJIGRjGzLvHZ1qw0v7v2k232WNsc91FcBuqZX rf4jIfKfp9uuY51RrEx17Z5U3H3rNKmeGFW2AgT7IKA8tph8Jg0wcSnKw+RIKUqSiekw PJHIJT1vG7oOksnSmy2xm5hQdIlDWjFPayvKpzHuvVty3y2FKbCudhEHkfUQl658P2Cf 0n3hW+5p0EZSEX56s1WnrAp3EYRbaxcoNeCw3vocspysd8EC86gjztABXJIc0aWni7r4 yCeWMvVjhNCoYCwtlLZnoGYT7yiVktKMywkpaF+o6tDt9n7UvAJoQbod0u0gS3lOvo/6 oy0A== X-Gm-Message-State: ALoCoQkYd9tBrnbZPmyBBELPNKUktmOjFWA/vojrG2lsSfCPzGddGL4wJSXUyWDks6RUZjyGVyve X-Received: by 10.180.81.163 with SMTP id b3mr23615705wiy.72.1413836719739; Mon, 20 Oct 2014 13:25:19 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id xw9sm13037669wjc.24.2014.10.20.13.25.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Oct 2014 13:25:18 -0700 (PDT) From: Thomas Monjalon To: "Carew, Alan" Date: Mon, 20 Oct 2014 22:25:03 +0200 Message-ID: <2678306.cvz6Un7zzm@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <0E29434AEE0C3A4180987AB476A6F6306D281C01@IRSMSX109.ger.corp.intel.com> References: <1413818593-26269-1-git-send-email-alan.carew@intel.com> <0E29434AEE0C3A4180987AB476A6F6306D281C01@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org 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, 20 Oct 2014 20:17:07 -0000 Hi Alan, 2014-10-20 15:26, Carew, Alan: > 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? librte_cmdline derivates from libcmdline written by Olivier Matz: http://git.droids-corp.org/?p=libcmdline.git Maybe there are some fixes to take here, and probably Olivier will have some good insights. > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alan Carew > > Sent: Monday, October 20, 2014 4:23 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] [PATCH] librte_cmdline: FreeBSD Fix oveflow when size of > > command result structure is greater than BUFSIZ > > > > When using test-pmd with flow director in FreeBSD, the application will > > segfault/Bus error while parsing the command-line. This is due to how > > each commands result structure is represented during parsing, where the offsets > > for each tokens value is stored in a character array(char result_buf[BUFSIZ]) > > in cmdline_parse()(./lib/librte_cmdline/cmdline_parse.c). > > > > The overflow occurs where BUFSIZ is less than the size of a commands result > > structure, in this case "struct cmd_pkt_filter_result" > > (app/test-pmd/cmdline.c) is 1088 bytes and BUFSIZ on FreeBSD is 1024 bytes as > > opposed to 8192 bytes on Linux. > > > > This patch removes the OS dependency on BUFSIZ and defines and uses a > > library #define CMDLINE_PARSE_RESULT_BUFSIZE 8192 > > > > The problem can be reproduced by running test-pmd on FreeBSD: > > ./testpmd -c 0x3 -n 4 -- -i --portmask=0x3 --pkt-filter-mode=perfect > > And adding a filter: > > add_perfect_filter 0 udp src 192.168.0.0 1024 dst 192.168.0.0 1024 flexbytes > > 0x800 vlan 0 queue 0 soft 0x17 > > > > Signed-off-by: Alan Carew > > --- > > lib/librte_cmdline/cmdline_parse.c | 2 +- > > lib/librte_cmdline/cmdline_parse.h | 3 +++ > > 2 files changed, 4 insertions(+), 1 deletion(-) [...] > > --- a/lib/librte_cmdline/cmdline_parse.c > > +++ b/lib/librte_cmdline/cmdline_parse.c > > @@ -219,7 +219,7 @@ cmdline_parse(struct cmdline *cl, const char * buf) > > unsigned int inst_num=0; > > cmdline_parse_inst_t *inst; > > const char *curbuf; > > - char result_buf[BUFSIZ]; > > + char result_buf[CMDLINE_PARSE_RESULT_BUFSIZE]; [...] > > --- a/lib/librte_cmdline/cmdline_parse.h > > +++ b/lib/librte_cmdline/cmdline_parse.h > > @@ -80,6 +80,9 @@ extern "C" { > > #define CMDLINE_PARSE_COMPLETE_AGAIN 1 > > #define CMDLINE_PARSE_COMPLETED_BUFFER 2 > > > > +/* maximum buffer size for parsed result */ > > +#define CMDLINE_PARSE_RESULT_BUFSIZE 8192 > > +