From patchwork Wed Mar 2 08:51:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: max X-Patchwork-Id: 590890 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4116A140773 for ; Wed, 2 Mar 2016 19:51:34 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=TiQpQcjt; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=LWnJ8TBMrLSOUHwfPhQcA5BNF2mkaHRp0EY2MhvpdZlBtyVWLR GuUZbBJjsip4MjugoDGYZ8675NJykYOpqL731r6QqJs+rGPO9U0PpMj9pxsoLLBz o/bfOLqOedXWgLhr/iz9c9pG8Xmmw6RaI7i4Ne6a9Clb5U5I+WEUYDjWI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:message-id:date:mime-version:content-type; s= default; bh=DQp3hwNWO14BPCuSZ2MrgRFSc9s=; b=TiQpQcjtnBBrPoeTFMdC uUYTeVF55qcQz7jCDqQTC+JQjKTMsPPkFqmfe2kd4GjLXrEfGr1P+RQV3bZPtKa8 xy5AtQScaGU2Q09wJ2ownTv4KIQQmMxKfUE3AarJyklTGfRUYeItKkN1I9VIxcLe agdtkS+cIvt2AGJSH/GD66U= Received: (qmail 77744 invoked by alias); 2 Mar 2016 08:51:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 77719 invoked by uid 89); 2 Mar 2016 08:51:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD, SPF_HELO_PASS, T_HDRS_LCASE, T_MANY_HDRS_LCASE autolearn=no version=3.3.2 spammy=sk:backtra, H*r:Wed, 2016-03-02, 20160302 X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 02 Mar 2016 08:51:23 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O3E00COYLXHP820@mailout2.w1.samsung.com> for gcc-patches@gcc.gnu.org; Wed, 02 Mar 2016 08:51:17 +0000 (GMT) Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id A2.05.16778.589A6D65; Wed, 2 Mar 2016 08:51:17 +0000 (GMT) Received: from [106.109.128.194] by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O3E00L98LXGDP10@eusync4.samsung.com>; Wed, 02 Mar 2016 08:51:17 +0000 (GMT) From: Maxim Ostapenko To: GCC Patches , iant@google.com Cc: Yury Gribov , Vyacheslav Barinov , Slava Garbuzov Subject: [PATCH, Libbacktrace] Fix possible SEGV when handling stripped PIE binaries. Message-id: <56D6A981.8070102@partner.samsung.com> Date: Wed, 02 Mar 2016 11:51:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------000200020004090703020509 X-IsSubscribed: yes Hi! When testing ASan on large system, I've noticed that sometimes it crashes with SEGV in Libbacktrace when trying to symbolize stripped PIE (compiled with -pie -fPIC) binaries in fully stripped environment (this means that all dependent libraries are also stripped). Here a scenario I've observed: 1) _asan_backtrace_initialize calls elf_add passing &elf_fileline_fn as output parameter to properly initialize it. 2) elf_add doesn't elf_fileline_fn initialize and returns -1 for stripped PIE binary. 3) _asan_backtrace_initialize calls phdr_callback on each dependent library via dl_iterate_phdr. 4) phdr_callback initializes elf_fileline_fn iff it found debug info in some library (found_dwarf == 1), but this is false since all libs are stripped. So, we still have uninitialized elf_fileline_fn value. 5) _asan_backtrace_initialize uses elf_fileline_fn to initialize proper fileline_fn callback. 6) Libbacktrace uses fileline_fn callback later and crashes because it contains garbage. This patch fixes the issue by simply initializing elf_fileline_fn via elf_nodebug in _asan_backtrace_initialize prologue. Tested on x86_64-linux-gnu and arm-linux-gnueabi, OK for trunk? -Maxim libbacktrace/ChangeLog: 2016-03-02 Maxim Ostapenko * elf.c (backtrace_initialize): Properly initialize elf_fileline_fn to avoid possible crash. diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c index 05cc5c0..c7168c6 100644 --- a/libbacktrace/elf.c +++ b/libbacktrace/elf.c @@ -925,7 +925,7 @@ backtrace_initialize (struct backtrace_state *state, int descriptor, int ret; int found_sym; int found_dwarf; - fileline elf_fileline_fn; + fileline elf_fileline_fn = elf_nodebug; struct phdr_data pd; ret = elf_add (state, descriptor, 0, error_callback, data, &elf_fileline_fn,