From patchwork Wed Dec 12 11:10:54 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yongseok Koh X-Patchwork-Id: 48698 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 52FA41B2AB; Wed, 12 Dec 2018 12:11:24 +0100 (CET) Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id 44D0C1B273 for ; Wed, 12 Dec 2018 12:11:23 +0100 (CET) Received: from Internal Mail-Server by MTLPINE1 (envelope-from yskoh@mellanox.com) with ESMTPS (AES256-SHA encrypted); 12 Dec 2018 13:17:31 +0200 Received: from scfae-sc-2.mti.labs.mlnx (scfae-sc-2.mti.labs.mlnx [10.101.0.96]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id wBCBBJ7A009852; Wed, 12 Dec 2018 13:11:20 +0200 From: Yongseok Koh To: anatoly.burakov@intel.com Cc: dev@dpdk.org, stable@dpdk.org Date: Wed, 12 Dec 2018 03:10:54 -0800 Message-Id: <20181212111054.35935-1-yskoh@mellanox.com> X-Mailer: git-send-email 2.11.0 Subject: [dpdk-dev] [PATCH] malloc: fix finding maximum contiguous IOVA size X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" malloc_elem_find_max_iova_contig() could return invalid size due to a missing sanity check. The following gdb output shows how 'cur_size' can be invalid in find_biggest_element(). (gdb) p/x cur_size $4 = 0xffffffffffe42900 (gdb) p elem $1 = (struct malloc_elem *) 0x12e842000 (gdb) p *elem $2 = {heap = 0x7ffff7ff387c, prev = 0x12e831fc0, next = 0x12e842900, free_list = {le_next = 0x109538000, le_prev = 0x7ffff7ff3894}, msl = 0x7ffff7ff107c, state = ELEM_FREE, pad = 0, size = 2304} (gdb) p *elem->msl $5 = {{base_va = 0x100200000, addr_64 = 4297064448}, page_sz = 2097152, socket_id = 0, version = 790, len = 17179869184, external = 0, memseg_arr = {name = "memseg-2048k-0-0", '\000' , count = 493, len = 8192, elt_sz = 48, data = 0x10002e000, rwlock = {cnt = 0}}} Fixes: 9fe6bceafd51 ("malloc: add finding biggest free IOVA-contiguous element") Cc: stable@dpdk.org Cc: anatoly.burakov@intel.com Signed-off-by: Yongseok Koh Acked-by: Anatoly Burakov --- lib/librte_eal/common/malloc_elem.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 9d3dcb6a9e..052aeeb7be 100644 --- a/lib/librte_eal/common/malloc_elem.c +++ b/lib/librte_eal/common/malloc_elem.c @@ -38,6 +38,10 @@ malloc_elem_find_max_iova_contig(struct malloc_elem *elem, size_t align) /* segment must start after header and with specified alignment */ contig_seg_start = RTE_PTR_ALIGN_CEIL(data_start, align); + /* return if aligned address is already out of malloc element */ + if (contig_seg_start > data_end) + return 0; + /* if we're in IOVA as VA mode, or if we're in legacy mode with * hugepages, all elements are IOVA-contiguous. however, we can only * make these assumptions about internal memory - externally allocated