From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 966983858D32 for ; Tue, 23 Aug 2022 11:57:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 966983858D32 Received: by mail-pj1-x1029.google.com with SMTP id x63-20020a17090a6c4500b001fabbf8debfso14389677pjj.4 for ; Tue, 23 Aug 2022 04:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc; bh=h8OhLKRfdUrR/pS/iXCF8SsJHA9ZNVDK44ZNWa32+T4=; b=PuXuQPeZnby9lLChx0UAaX9kAh8KHBRD2iq/r01muHTqHmggQCe0loieHrl8p9fSyQ l3s6+mx+92lobP6OY53AWebaqUjcL0rq7CkbqfM1rDNGaJMOdkyr1YiYdPpY1AifgJyL A0lGjklCi02uhd0aDfRrxVr+kQalZf8a1qHXDwdCStt6q9CS4nPszyt9XLWfky/pM9Ga cYU6GfLvw8LTHFXiv4o3fX7E2Tt7UT+IxI7AiYm+EaL0mmuRonaCUxfBOAwc4HBe4NN7 e9onNGiaj8AknWHxnxt5TOVA+OYUhNlvhQFZX4u4PuhIayrOseGoQGKOYAxoexuYJe+v c2+g== X-Gm-Message-State: ACgBeo2SuQcUOgDLle5QCtG+Joff1fbRPQfZH7yDmKrL+RQYGciRa2eU b0N/ZMtQ6DmIvxJaPpANtiZ8OZ3oTcE= X-Google-Smtp-Source: AA6agR4+83h9KbyGRfIlWDe/XTyp/6GUfoQ3V5iBIpjW2qAufxufdDoxjMixV/giqpjjyu2UzaxJHQ== X-Received: by 2002:a17:90b:1c12:b0:1fa:e52a:bd88 with SMTP id oc18-20020a17090b1c1200b001fae52abd88mr2924535pjb.24.1661255820385; Tue, 23 Aug 2022 04:57:00 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id 9-20020a17090a0e8900b001f56315f9efsm11691968pjx.32.2022.08.23.04.56.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 04:56:59 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 252911141ABE; Tue, 23 Aug 2022 21:26:57 +0930 (ACST) Date: Tue, 23 Aug 2022 21:26:57 +0930 From: Alan Modra To: binutils@sourceware.org Subject: SHT_RELR sh_link and sh_info Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3036.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 23 Aug 2022 11:57:03 -0000 I don't think it makes any sense for a SHT_RELR section to specify a symbol table with sh_link. SHT_RELR relocations don't use symbols. There is no real need to specify sh_info either, SHT_RELR is not for relocatable object files. Anyway, fuzzers of course don't restrict themselves to even half-sensible objects. So they found a hole in objcopy using a non-alloc SHT_RELR in an ET_EXEC. In that case BFD set up the SHT_RELR section as if it were a SHT_REL against the sh_info target section. When it came to reading in the target section relocs, the count was horribly wrong which caused a buffer overflow. * elf.c (bfd_section_from_shdr ): Always just make a normal section, don't treat it as a reloc section. diff --git a/bfd/elf.c b/bfd/elf.c index f186a2cffe9..8aba36acb3c 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -2409,6 +2409,7 @@ bfd_section_from_shdr (bfd *abfd, unsigned int shindex) its sh_link points to the null section. */ if (((abfd->flags & (DYNAMIC | EXEC_P)) != 0 && (hdr->sh_flags & SHF_ALLOC) != 0) + || hdr->sh_type == SHT_RELR || hdr->sh_link == SHN_UNDEF || hdr->sh_link != elf_onesymtab (abfd) || hdr->sh_info == SHN_UNDEF -- Alan Modra Australia Development Lab, IBM