From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29550 invoked by alias); 15 Oct 2010 09:54:30 -0000 Received: (qmail 29535 invoked by uid 22791); 15 Oct 2010 09:54:29 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Oct 2010 09:54:25 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o9F9sNl3013388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Oct 2010 05:54:23 -0400 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id o9F9sLEq002902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Oct 2010 05:54:23 -0400 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o9F9sLFI001645 for ; Fri, 15 Oct 2010 11:54:21 +0200 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o9F9sLBt001639 for binutils@sourceware.org; Fri, 15 Oct 2010 11:54:21 +0200 Date: Fri, 15 Oct 2010 09:54:00 -0000 From: Jan Kratochvil To: binutils@sourceware.org Subject: relent->sym_ptr_ptr memory stale refs question Message-ID: <20101015095420.GA17502@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00225.txt.bz2 Hi, there has been a GDB thread about stale memory reference / crashes: Re: [patch] Fix ELF stale reference http://sourceware.org/ml/gdb-patches/2010-09/msg00192.html http://sourceware.org/ml/gdb-patches/2010-10/msg00244.html elfcode.h:elf_slurp_reloc_table_from_section contains: ps = symbols + ELF_R_SYM (rela.r_info) - 1; relent->sym_ptr_ptr = ps; This way it embeds references to the memory area passed as DYNSYMS to bfd_get_synthetic_symtab persistently into abfd. But the application does not know when it can already free the DYNSYMS pointers array memory as the same abfd can be used from various places - reference counted by GDB now, sure GDB could make its own association of that memory block with abfd. FYI binutils/ nm never frees the memory. objdump frees it also prematurely in dump_bfd - although it is not exploitable as the program immediately exits afterwards. By duplicating the dump_bfd calls twice we get for `objdump -d': Invalid read of size 8 at 0x5A4710: _bfd_elf_get_synthetic_symtab (elf.c:9336) by 0x4091D9: dump_bfd (objdump.c:3082) by 0x409459: display_bfd (objdump.c:3160) by 0x409657: display_file (objdump.c:3242) by 0x409E6D: main (objdump.c:3504) Address 0x58143b8 is 8 bytes inside a block of size 24 free'd at 0x4C25D72: free (vg_replace_malloc.c:325) by 0x4093C1: dump_bfd (objdump.c:3137) by 0x40944D: display_bfd (objdump.c:3159) by 0x409657: display_file (objdump.c:3242) by 0x409E6D: main (objdump.c:3504) I find this too fragile. Application can also use bfd_alloc but its declaration is in libbfd.h: /* libbfd.h -- Declarations used by bfd library *implementation*. (This include file is not for users of the library.) Also bfd_alloc would mean the memory is not freeable during multiple executions of bfd_get_synthetic_symtab. The passed memory gets no longer used during 2nd and further runs as asect->relocation != NULL in elf_slurp_reloc_table. Do you suggest a way to change the bfd/ API or is GDB free to use bfd_alloc? Thanks, Jan