From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A54674300E; Tue, 8 Aug 2023 19:59:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3927241148; Tue, 8 Aug 2023 19:59:39 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id F2335410E6 for ; Tue, 8 Aug 2023 19:59:37 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 55AF4208F5A7; Tue, 8 Aug 2023 10:59:37 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 55AF4208F5A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691517577; bh=ryGh8BcUqWhGDMaRklvnv6jFOhZiLzYNeDfjqBh0QOc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=c2vgKvrF6r0gFS5UepGVqclSCjZy3HgXlzVRycOsfHmQZhuuz3URqqcnFPpkssWyt qEqBa1/gx2ZZLh5qHBWsX15Du6vJZ5B/JzmlaxlA0tJ4R1kEt+GdClwteBMM0FKiOP GzWC5EnI79+Y3+5+5iRumzUc4gsM6y9ywcl18lk0= Date: Tue, 8 Aug 2023 10:59:37 -0700 From: Tyler Retzlaff To: "lihuisong (C)" Cc: dev@dpdk.org, Ciara Power , bruce.richardson@intel.com Subject: Re: [PATCH] telemetry: avoid truncation of strlcpy return before check Message-ID: <20230808175937.GA13736@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1691011261-5666-1-git-send-email-roretzla@linux.microsoft.com> <35199239-fac5-f7f2-6f80-5070b016d7d6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <35199239-fac5-f7f2-6f80-5070b016d7d6@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Aug 08, 2023 at 10:24:41AM +0800, lihuisong (C) wrote: > > 在 2023/8/3 5:21, Tyler Retzlaff 写道: > >strlcpy returns type size_t when directly assigning to > >struct rte_tel_data data_len field it may be truncated leading to > >compromised length check that follows > > > >Since the limit in the check is < UINT_MAX the value returned is > >safe to be cast to unsigned int (which may be narrower than size_t) > >but only after being checked against RTE_TEL_MAX_SINGLE_STRING_LEN > > > >Signed-off-by: Tyler Retzlaff > >--- > > lib/telemetry/telemetry_data.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > >diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c > >index 3b1a240..52307cb 100644 > >--- a/lib/telemetry/telemetry_data.c > >+++ b/lib/telemetry/telemetry_data.c > >@@ -41,12 +41,13 @@ > > int > > rte_tel_data_string(struct rte_tel_data *d, const char *str) > > { > >+ const size_t len = strlcpy(d->data.str, str, sizeof(d->data.str)); > sizeof(d->data.str) is equal to RTE_TEL_MAX_SINGLE_STRING_LEN(8192). > So It seems that this truncation probably will not happen. agreed, regardless the data type choices permit a size that exceeds the range of the narrower type and the assignment results in a warning being generated on some targets. that's why the truncating cast is safe to add. none of this would be necessary if data_len had been appropriately typed as size_t. Bruce should we be changing the type instead since we are in 23.11 merge window...?