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 7A0CCA034E for ; Fri, 15 May 2020 08:32:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5F5101DA04; Fri, 15 May 2020 08:32:12 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 6DCAB1D6B3; Fri, 15 May 2020 08:32:09 +0200 (CEST) IronPort-SDR: AfE4v6cDU2A4hVSoV4A1ZXI+XafyDOKxVO6rnQgxm5T/izYCk5wE3QWVuYXDj2GAoepwgheRXO avbcaOBDdeWg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2020 23:32:08 -0700 IronPort-SDR: nPQbzvY4e7KcZfIx6LvLWRMxZgfJKIj3sR/6ZCd8+Let0Hwq/s0gAJK125xvCnrTWs7scRXs+c g6zGYj+k5Syw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,394,1583222400"; d="scan'208";a="464619860" Received: from jguo15x-mobl.ccr.corp.intel.com (HELO [10.67.68.85]) ([10.67.68.85]) by fmsmga005.fm.intel.com with ESMTP; 14 May 2020 23:32:06 -0700 To: Wei Zhao , dev@dpdk.org Cc: stable@dpdk.org, beilei.xing@intel.com References: <20200512151915.105152-1-wei.zhao1@intel.com> From: Jeff Guo Message-ID: Date: Fri, 15 May 2020 14:32:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200512151915.105152-1-wei.zhao1@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/i40e: fix the security risk of wild pointer operation 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" hi, zhaowei On 5/12/2020 11:19 PM, Wei Zhao wrote: > In i40e PMD code of function i40e_res_pool_free(), if valid_entry is > freed by "rte_free(valid_entry);" in the following code: > > if (prev != NULL) { > ........................ > > if (insert == 1) { > LIST_REMOVE(valid_entry, next); > rte_free(valid_entry); > } else { > rte_free(valid_entry); > insert = 1; > } > } > > then the following code for pool update may still use the wild pointer > "valid_entry": > > " pool->num_free += valid_entry->len; > pool->num_alloc -= valid_entry>len; > " > it seems to be a security bug, we should avoid this risk. > > Cc: stable@dpdk.org > Fixes: 4861cde46116 ("i40e: new poll mode driver") > > Signed-off-by: Wei Zhao > --- > drivers/net/i40e/i40e_ethdev.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c > index 749d85f54..7f8ea5309 100644 > --- a/drivers/net/i40e/i40e_ethdev.c > +++ b/drivers/net/i40e/i40e_ethdev.c > @@ -4973,6 +4973,9 @@ i40e_res_pool_free(struct i40e_res_pool_info *pool, > } > > insert = 0; > + pool->num_free += valid_entry->len; > + pool->num_alloc -= valid_entry->len; > + Shouldn't the pool count update after the pool->free_list updated by "LIST_INSERT_HEAD(&pool->free_list, valid_entry, next)"? If so, you could use a variable to restore  valid_entry->len at the begin and use it update pool count and other place. > /* Try to merge with next one*/ > if (next != NULL) { > /* Merge with next one */ > @@ -5010,9 +5013,6 @@ i40e_res_pool_free(struct i40e_res_pool_info *pool, > LIST_INSERT_HEAD(&pool->free_list, valid_entry, next); > } > > - pool->num_free += valid_entry->len; > - pool->num_alloc -= valid_entry->len; > - > return 0; > } >