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 20CFF42861; Thu, 30 Mar 2023 13:34:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A5E0A410D3; Thu, 30 Mar 2023 13:34:15 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id C0F6740E25 for ; Thu, 30 Mar 2023 13:34:13 +0200 (CEST) Received: from dggpeml500018.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4PnLsJ1jL2zKpr9 for ; Thu, 30 Mar 2023 19:33:40 +0800 (CST) Received: from dggpeml500021.china.huawei.com (7.185.36.21) by dggpeml500018.china.huawei.com (7.185.36.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 30 Mar 2023 19:34:10 +0800 Received: from dggpeml500021.china.huawei.com ([7.185.36.21]) by dggpeml500021.china.huawei.com ([7.185.36.21]) with mapi id 15.01.2507.021; Thu, 30 Mar 2023 19:34:10 +0800 From: "wuchangsheng (C)" To: "anatoly.burakov@intel.com" CC: "dev@dpdk.org" , "jiangheng (G)" , "Yanan (Euler)" Subject: malloc_heap: Possible Control Block Overwrite When Insufficient Space in Elem Thread-Topic: malloc_heap: Possible Control Block Overwrite When Insufficient Space in Elem Thread-Index: Adli+zGgtSM0h9CtRpalxA7PElP6hA== Date: Thu, 30 Mar 2023 11:34:10 +0000 Message-ID: <08db5578898e483992ab35bfacb424c5@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.112.45] Content-Type: multipart/alternative; boundary="_000_08db5578898e483992ab35bfacb424c5huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 --_000_08db5578898e483992ab35bfacb424c5huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I seem to have discovered a problem in the heap memory allocation and deall= ocation operations. |------------------|----------------------------| elem padsize newelem In the malloc_elem_alloc function, when padsize > cache-line (such as 64 by= tes) and padsize < sizeof(struct malloc_elem), the initialization of new_el= em will overwrite and damage the struct malloc_elem information of elem, wh= ile setting the state of new_elem to ELEM_PAD. When releasing new_elem in m= alloc_elem_free, it will be converted to elem using RTE_PTR_SUB(new_elem, n= ew_elem->pad), but at this point, the struct malloc_elem information of ele= m is damaged. --_000_08db5578898e483992ab35bfacb424c5huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I seem to have discovered a problem in the heap memory allocation and = deallocation operations.

    |------------------|----------------------------|

  elem  padsize    newelem

In the malloc_elem_alloc function, when padsize > cache-line (such = as 64 bytes) and padsize < sizeof(struct malloc_elem), the initializatio= n of new_elem will overwrite and damage the struct malloc_elem information of elem, while setting the state of new_ele= m to ELEM_PAD. When releasing new_elem in malloc_elem_free, it will be conv= erted to elem using RTE_PTR_SUB(new_elem, new_elem->pad), but at this po= int, the struct malloc_elem information of elem is damaged.

 

--_000_08db5578898e483992ab35bfacb424c5huaweicom_--