From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5907 invoked by alias); 17 May 2005 18:09:15 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 3671 invoked from network); 17 May 2005 18:07:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 May 2005 18:07:28 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4HI7SxP009741 for ; Tue, 17 May 2005 14:07:28 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4HI7RO25247; Tue, 17 May 2005 14:07:27 -0400 Received: from [172.31.0.98] (vpnuser7.surrey.redhat.com [172.16.9.7]) by pobox.surrey.redhat.com (8.12.8/8.12.8) with ESMTP id j4HI7QMO027689; Tue, 17 May 2005 19:07:26 +0100 Message-ID: <428A330B.3050601@redhat.com> Date: Tue, 17 May 2005 18:25:00 -0000 From: Nick Clifton User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Mike Frysinger CC: binutils@sources.redhat.com Subject: Re: BFD overflows (part 2) References: <200505120736.35805.vapier@gentoo.org> In-Reply-To: <200505120736.35805.vapier@gentoo.org> Content-Type: multipart/mixed; boundary="------------020606040603090301000205" X-SW-Source: 2005-05/txt/msg00546.txt.bz2 This is a multi-part message in MIME format. --------------020606040603090301000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 694 Hi Mike, > strings.095: > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000418678 in bfd_elf_string_from_elf_section (abfd=0x4643a0, > shindex=5784064, strindex=47) at elf.c:280 This was a nasty one - the file was stimulating an infinite loop inside the code in elf.c between group_signature() and bfd_section_from_shdr(). Anyway I will be checking in the attached patch to catch and prevent this occurring in the future. Cheers Nick bfd/ChangeLog 2005-05-17 Nick Clifton * elf.c (group_signature): Check for a group section which is actually a (corrupt) symbol table section in disguise and prevent an infinite loop from occurring. --------------020606040603090301000205 Content-Type: text/plain; name="elf.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="elf.c.patch" Content-length: 1543 Index: bfd/elf.c =================================================================== RCS file: /cvs/src/src/bfd/elf.c,v retrieving revision 1.293 diff -c -3 -p -r1.293 elf.c *** bfd/elf.c 17 May 2005 16:23:26 -0000 1.293 --- bfd/elf.c 17 May 2005 18:00:45 -0000 *************** group_signature (bfd *abfd, Elf_Internal *** 451,458 **** unsigned char esym[sizeof (Elf64_External_Sym)]; Elf_External_Sym_Shndx eshndx; Elf_Internal_Sym isym; ! /* First we need to ensure the symbol table is available. */ if (! bfd_section_from_shdr (abfd, ghdr->sh_link)) return NULL; --- 451,473 ---- unsigned char esym[sizeof (Elf64_External_Sym)]; Elf_External_Sym_Shndx eshndx; Elf_Internal_Sym isym; + unsigned int i; + + if (ghdr == NULL) + return NULL; + + /* If this section is linked to by other sections then it is a symbol or + string section which is masquerading as a group. This is a bad thing, + and if we carry on to the call to bfd_section_from_shdr below we will + enter an infinite loop. So check now and break out if we detect this + case. See: + http://sources.redhat.com/ml/binutils/2005-05/msg00421.html + for a report of a case that tirggers this code. */ + for (i = elf_numsections (abfd); i--;) + if (elf_elfsections (abfd) [elf_elfsections (abfd) [i]->sh_link] == ghdr) + return NULL; ! /* Next we need to ensure the symbol table is available. */ if (! bfd_section_from_shdr (abfd, ghdr->sh_link)) return NULL; --------------020606040603090301000205--