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 2C1C9A0C43; Fri, 22 Oct 2021 11:07:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B03D841103; Fri, 22 Oct 2021 11:07:56 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id C41414069D; Fri, 22 Oct 2021 11:07:54 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10144"; a="292726023" X-IronPort-AV: E=Sophos;i="5.87,172,1631602800"; d="scan'208";a="292726023" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2021 02:07:53 -0700 X-IronPort-AV: E=Sophos;i="5.87,172,1631602800"; d="scan'208";a="484606253" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.0.203]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Oct 2021 02:07:52 -0700 Date: Fri, 22 Oct 2021 10:07:48 +0100 From: Bruce Richardson To: Vladimir Medvedkin Cc: dev@dpdk.org, david.marchand@redhat.com, alex@therouter.net, stable@dpdk.org Message-ID: References: <1633728537-197824-1-git-send-email-vladimir.medvedkin@intel.com> <1634836549-10800-1-git-send-email-vladimir.medvedkin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1634836549-10800-1-git-send-email-vladimir.medvedkin@intel.com> Subject: Re: [dpdk-dev] [PATCH v2] lpm: fix buffer overflow 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 Sender: "dev" On Thu, Oct 21, 2021 at 06:15:49PM +0100, Vladimir Medvedkin wrote: > This patch fixes buffer overflow reported by ASAN, > please reference https://bugs.dpdk.org/show_bug.cgi?id=819 > > The rte_lpm6 keeps routing information for control plane purpose > inside the rte_hash table which uses rte_jhash() as a hash function. > From the rte_jhash() documentation: If input key is not aligned to > four byte boundaries or a multiple of four bytes in length, > the memory region just after may be read (but not used in the > computation). > rte_lpm6 uses 17 bytes keys consisting of IPv6 address (16 bytes) + > depth (1 byte). > > This patch increases the size of the depth field up to uint32_t > and sets the alignment to 4 bytes. > > Bugzilla ID: 819 > Fixes: 86b3b21952a8 ("lpm6: store rules in hash table") > Cc: alex@therouter.net > Cc: stable@dpdk.org > > Signed-off-by: Vladimir Medvedkin Acked-by: Bruce Richardson