From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id D47553858C2C for ; Thu, 9 Sep 2021 09:51:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D47553858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 4088B92009C; Thu, 9 Sep 2021 11:51:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 3A49692009B; Thu, 9 Sep 2021 11:51:48 +0200 (CEST) Date: Thu, 9 Sep 2021 11:51:48 +0200 (CEST) From: "Maciej W. Rozycki" To: Alan Modra cc: Chenghua Xu , binutils@sourceware.org Subject: Re: PR28306, segfault in _bfd_mips_elf_reloc_unshuffle In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1168.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 09:51:51 -0000 On Wed, 8 Sep 2021, Alan Modra wrote: > Protect the _bfd_mips_elf_reloc_unshuffle call in mips16_gprel_reloc > by checking the reloc offset. The other changes catch potential > buffer overflows when processing relocations near the end of a > section. > > OK to apply? Thank you for working on this issue. Overall it looks good to me, but see one question below. > diff --git a/bfd/elfn32-mips.c b/bfd/elfn32-mips.c > index dc607e776d1..2ab0bae976a 100644 > --- a/bfd/elfn32-mips.c > +++ b/bfd/elfn32-mips.c > @@ -877,7 +877,7 @@ static reloc_howto_type elf_mips_howto_table_rela[] = > /* No relocation. */ > HOWTO (R_MIPS_NONE, /* type */ > 0, /* rightshift */ > - 0, /* size (0 = byte, 1 = short, 2 = long) */ > + 3, /* size (0 = byte, 1 = short, 2 = long) */ > 0, /* bitsize */ > false, /* pc_relative */ > 0, /* bitpos */ This might well be a separate change, applied right away as obvious. > diff --git a/bfd/elfxx-mips.c b/bfd/elfxx-mips.c > index e4827fd17de..aef5ede3ef0 100644 > --- a/bfd/elfxx-mips.c > +++ b/bfd/elfxx-mips.c [...] > @@ -2595,9 +2598,19 @@ _bfd_mips_elf_generic_reloc (bfd *abfd ATTRIBUTE_UNUSED, arelent *reloc_entry, > bfd_reloc_status_type status; > bool relocatable; > > + /* ld -r or gas. */ > relocatable = (output_bfd != NULL); > > - if (reloc_entry->address > bfd_get_section_limit (abfd, input_section)) > + /* We only use bfd_reloc_offset_in_range for final linking because > + mips object files may use relocations that seem to access beyond > + section limits. gas/testsuite/gas/mips/dla-reloc.s is an example > + that puts R_MIPS_SUB, a 64-bit relocation, on the last > + instruction in the section. If final linking that object file > + the R_MIPS_SUB won't be processed here since it applies to the > + addend for the next reloc rather than the section contents. */ > + if (!relocatable > + && !bfd_reloc_offset_in_range (reloc_entry->howto, abfd, > + input_section, reloc_entry->address)) > return bfd_reloc_outofrange; Would a correct check be feasible here? For a composed relocation only the final entry is applied to output, so could we instead check if there is a follow-up relocation? Maciej