From patchwork Wed Mar 2 14:21:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: max X-Patchwork-Id: 590993 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 4A1921400A0 for ; Thu, 3 Mar 2016 01:21:36 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=bQnOOy+b; 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 :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=WMJtHEvpsqkOsffaE Iv7ex/8BGpExjAGOoEtumvYdYFOy28FT8qHpNTSbuTUX+9qsXHkLkkJPXhZrF9HA 1u7Cbkq5ClRtu6d89lvQfNWXxpWqQucDX+EePT/HXiSX+a154ZAxapA0o5B/9lmD mXINZQepG4LsSg4XzDVO7QoVVY= 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 :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=pY36I52kYP++3ZX//VmgVbX 8vC0=; b=bQnOOy+bDHuNvIbDFKR0N53chbaPVNW9XJQDS8912i6QFZAnPlVP5f5 ThHExYg08YN/9lSVq7dtMKFYQDpxPLZCGgwahOSaJHL1FNN4hQ4NEo06caU8LhSR IV4lBPKyW/H5JV8XA7WmK0pwV4fJMUKUyXFPQXtleOPQGTkAeld0= Received: (qmail 105231 invoked by alias); 2 Mar 2016 14:21:30 -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 105220 invoked by uid 89); 2 Mar 2016 14:21:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=BAYES_40, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=no version=3.3.2 spammy=sk:backtra, phdr_data, elfc, 925, 7 X-HELO: mailout4.w1.samsung.com Received: from mailout4.w1.samsung.com (HELO mailout4.w1.samsung.com) (210.118.77.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 02 Mar 2016 14:21:28 +0000 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O3F0063E17MSUB0@mailout4.w1.samsung.com> for gcc-patches@gcc.gnu.org; Wed, 02 Mar 2016 14:21:22 +0000 (GMT) Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 44.3E.21385.2E6F6D65; Wed, 2 Mar 2016 14:21:22 +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 <0O3F000YF17LA810@eusync4.samsung.com>; Wed, 02 Mar 2016 14:21:22 +0000 (GMT) Subject: Re: [PATCH, Libbacktrace] Fix possible SEGV when handling stripped PIE binaries. To: Ian Lance Taylor References: <56D6A981.8070102@partner.samsung.com> Cc: GCC Patches , Yury Gribov , Vyacheslav Barinov , Slava Garbuzov From: Maxim Ostapenko Message-id: <56D6F6DE.4090509@partner.samsung.com> Date: Wed, 02 Mar 2016 17:21:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: Content-type: multipart/mixed; boundary=------------060306070604060308080300 X-IsSubscribed: yes On 02/03/16 16:59, Ian Lance Taylor wrote: > On Wed, Mar 2, 2016 at 12:51 AM, Maxim Ostapenko > wrote: >> 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? > Thanks for the analysis. I would rather set *fileline_fn in the case > where elf_add returns -1. Or, remove the setting of *fileline_fn = > elf_nodebug in elf_add, since that would become the default. > > Ian > Thanks, does this look better (I used the second option)? -Maxim libbacktrace/ChangeLog: 2016-03-02 Maxim Ostapenko * elf.c (backtrace_initialize): Properly initialize elf_fileline_fn to avoid possible crash. (elf_add): Don't set *fileline_fn to elf_nodebug value in case of missing debug info anymore. diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c index 05cc5c0..f85ac65 100644 --- a/libbacktrace/elf.c +++ b/libbacktrace/elf.c @@ -791,7 +791,6 @@ elf_add (struct backtrace_state *state, int descriptor, uintptr_t base_address, { if (!backtrace_close (descriptor, error_callback, data)) goto fail; - *fileline_fn = elf_nodebug; return 1; } @@ -925,7 +924,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,