From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 6E8F2803D for ; Wed, 12 Oct 2016 08:44:06 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP; 11 Oct 2016 23:44:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,332,1473145200"; d="scan'208";a="771645999" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by FMSMGA003.fm.intel.com with ESMTP; 11 Oct 2016 23:44:03 -0700 Date: Wed, 12 Oct 2016 14:44:24 +0800 From: Yuanhan Liu To: Maciej Czekaj Cc: dpdk stable Message-ID: <57fddbc8.XxQCwzbvT4mT89DW%yuanhan.liu@linux.intel.com> User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dpdk-stable] patch 'mem: fix crash on hugepage mapping error' has been queued to stable release 16.07.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 06:44:07 -0000 Hi, FYI, your patch has been queued to stable release 16.07.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before this Friday. So please shutout if anyone has objections. Thanks. --yliu --- >>From e3ef4895da77499b9e956a0c7d65cf5fbcd38377 Mon Sep 17 00:00:00 2001 From: Maciej Czekaj Date: Wed, 28 Sep 2016 12:52:57 +0200 Subject: [PATCH] mem: fix crash on hugepage mapping error [ upstream commit c00ae961ff8dbc036322fdb41137a7dedac005c9 ] In ASLR-enabled system, it is possible that selected virtual space is occupied by program segments. Therefore, error path should not blindly unmap all memmory segments but only those already mapped. Steps that lead to crash: 1. memeseg 0 in secondary process overlaps with libc.so 2. mmap of /dev/zero fails for virtual space of memseg 0 3. munmap of memseg 0 leads to unmapping libc.so itself 4. app gets SIGSEGV after returning from syscall to libc Fixes: ea329d7f8e34 ("mem: fix leak after mapping failure") Signed-off-by: Maciej Czekaj --- lib/librte_eal/linuxapp/eal/eal_memory.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c index 41e0a92..575de63 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memory.c +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c @@ -1552,6 +1552,7 @@ rte_eal_hugepage_attach(void) struct hugepage_file *hp = NULL; unsigned num_hp = 0; unsigned i, s = 0; /* s used to track the segment number */ + unsigned max_seg = RTE_MAX_MEMSEG; off_t size; int fd, fd_zero = -1, fd_hugepage = -1; @@ -1619,6 +1620,9 @@ rte_eal_hugepage_attach(void) "in /dev/zero to requested address [%p]: '%s'\n", (unsigned long long)mcfg->memseg[s].len, mcfg->memseg[s].addr, strerror(errno)); + max_seg = s; + if (base_addr != MAP_FAILED) + munmap(base_addr, mcfg->memseg[s].len); if (aslr_enabled() > 0) { RTE_LOG(ERR, EAL, "It is recommended to " "disable ASLR in the kernel " @@ -1701,11 +1705,8 @@ rte_eal_hugepage_attach(void) return 0; error: - s = 0; - while (s < RTE_MAX_MEMSEG && mcfg->memseg[s].len > 0) { - munmap(mcfg->memseg[s].addr, mcfg->memseg[s].len); - s++; - } + for (i = 0; i < max_seg && mcfg->memseg[i].len > 0; i++) + munmap(mcfg->memseg[i].addr, mcfg->memseg[i].len); if (hp != NULL && hp != MAP_FAILED) munmap(hp, size); if (fd_zero >= 0) -- 1.9.0