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 E2738A04B6 for ; Mon, 12 Oct 2020 15:07:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E21981BCDE; Mon, 12 Oct 2020 15:06:56 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2B7F81E35; Mon, 12 Oct 2020 15:06:52 +0200 (CEST) IronPort-SDR: qjWKFuT/XeYz0oI1G9bHtcGl/CC6J010c3lg+PpWCCYwJCxun/R3P4R+yADxM0h8yYjs/M/Cg7 8SUlzTqiXZhg== X-IronPort-AV: E=McAfee;i="6000,8403,9771"; a="164949677" X-IronPort-AV: E=Sophos;i="5.77,366,1596524400"; d="scan'208";a="164949677" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 06:04:31 -0700 IronPort-SDR: NmLl7wUDYuH6ZKN/PRiao42+wxkt19TH2r8RznG6I+yBxFYEVqd6PDk0xOjbblct9jydAZU0Jw BHqev1H7oUGg== X-IronPort-AV: E=Sophos;i="5.77,366,1596524400"; d="scan'208";a="520686917" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.244.119]) ([10.213.244.119]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 06:04:30 -0700 To: Bruce Richardson Cc: Kevin Laatz , dev@dpdk.org, stephen@networkplumber.org, stable@dpdk.org References: <20200922172015.266698-1-kevin.laatz@intel.com> <20201001170902.487111-1-kevin.laatz@intel.com> <307b8070-977d-187f-c9c0-4b97477eda98@intel.com> <20201012124506.GB565@bricha3-MOBL.ger.corp.intel.com> From: Ferruh Yigit Message-ID: <80153586-6f6c-5227-9e0d-ffca61424045@intel.com> Date: Mon, 12 Oct 2020 14:04:26 +0100 MIME-Version: 1.0 In-Reply-To: <20201012124506.GB565@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [PATCH v2] net/ring: fix unchecked return value 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" On 10/12/2020 1:45 PM, Bruce Richardson wrote: > On Mon, Oct 12, 2020 at 12:57:11PM +0100, Ferruh Yigit wrote: >> On 10/1/2020 6:09 PM, Kevin Laatz wrote: >>> Add a check for the return value of the sscanf call in >>> parse_internal_args(), returning an error if we don't get the expected >>> result. >>> >>> Coverity issue: 362049 >>> Fixes: 96cb19521147 ("net/ring: use EAL APIs in PMD specific API") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Kevin Laatz >>> >>> --- >>> v2: added consumed characters count check >>> --- >>> drivers/net/ring/rte_eth_ring.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c >>> index 40fe1ca4ba..66367465fd 100644 >>> --- a/drivers/net/ring/rte_eth_ring.c >>> +++ b/drivers/net/ring/rte_eth_ring.c >>> @@ -538,8 +538,13 @@ parse_internal_args(const char *key __rte_unused, const char *value, >>> { >>> struct ring_internal_args **internal_args = data; >>> void *args; >>> + int n; >>> - sscanf(value, "%p", &args); >>> + if (sscanf(value, "%p%n", &args, &n) != 1 || (size_t)n != strlen(value)) { >> >> two small details, >> >> 1- I see following note in the sscanf manual: https://linux.die.net/man/3/sscanf >> " >> The C standard says: "Execution of a %n directive does not increment the >> assignment count returned at the completion of execution" but the >> Corrigendum seems to contradict this. Probably it is wise not to make any >> assumptions on the effect of %n conversions on the return value. >> " >> >> So what do you think checking return value as " == 0" ? >> > > Maybe in that copy of the man page but on my Ubuntu system there is no such > disclaimer, and I don't see it either on the kernel.org man page reference: > > https://man7.org/linux/man-pages/man3/sscanf.3.html > > That official man page reference clearly states that the behaviour is that > %n does not increase the reference count. > My Linux box also doesn't have that note, but just to prevent the PMD fails for something like this. Do you see any downside of checking as "sscanf() == 0"?