From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 76B3B3858D33 for ; Wed, 8 Feb 2023 00:32:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 76B3B3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62a.google.com with SMTP id r8so17513907pls.2 for ; Tue, 07 Feb 2023 16:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=U15Gf/rKMNf1VUZ1QG7p27EtCNQTBcmE6vjlWWkkuXs=; b=TXjJsk3ttraeSr8DCdAeMFpBZW57k2Rb7+R5GSuCR/NLehUTXvlYJUDaee1yAyX1+V HWrhvJrwAMdlbzQVF0LXiG90KofhZvnfmuI2UHDgflJrHSbZPXc75mTlYYIXdR0BaNz9 RCMgQfue3XgMA/j0brREoiuqM4r4AZzaDrWgSvw5AAogJdKryWVIkHrNunuumWdTUK3m JggDApD9YGZbPrgIAlnsrEuSLcZ6cbWrpr0j8tdpjobpuwIC6sNIsPBC0RNcSdYGAVYx mDWhwabCGYUupNNcJyWLDZAlxypdNvuEm0xQesDKuMQCLKKMMXb+zA79sXxBTIxQ7fXV je0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=U15Gf/rKMNf1VUZ1QG7p27EtCNQTBcmE6vjlWWkkuXs=; b=N7qKFEKB/rkdJWNQu3/zT5l6hnjUIMEWtFePYu9bklpyWpMt/Zh621F6bpDwCngXjZ GlsqQLY1QBiQreJUz404K0UjpiyohEjuvmRAEd1azvaQomgb74yJSB0+BKIck/V+9EaA FbNYN1ksEHob3jktwwyoAY1QyccccKqj0DgIe5sNiaAZvLuyHhl9gQGwlYtfKtkCMkcm dbTvaTidBhpphc5MsWzzgkkALXxZtD6mV6xwDe3HSlGCZUGg1UdbYCXqpgXyXDbELjk1 FbVnBoGnWuSpc2kEiQGXqRmydG46PBpDEVzjdYtEHDnvS+k2p+52X7Ne/TRoAELKA1Ey YKng== X-Gm-Message-State: AO0yUKWIrjqHQmOLakLgw83RQ2y1DxR1spOU4tdCj0ESI0mG+mhhNhVY +VbM3G6xCYg7rxg/ZEG6lJ7OFSevn1U= X-Google-Smtp-Source: AK7set/75/WXzlYCuqTTD+6zW73rSee67HEGPlLcNla5HZhA24n8bQ0wL/BgZMxFbzKs+eED1JUINQ== X-Received: by 2002:a17:90b:33c8:b0:230:a195:b8af with SMTP id lk8-20020a17090b33c800b00230a195b8afmr6565580pjb.10.1675816349417; Tue, 07 Feb 2023 16:32:29 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:5eaa:1b5:52fe:cab1]) by smtp.gmail.com with ESMTPSA id q11-20020a63750b000000b004da425922c6sm8585876pgc.74.2023.02.07.16.32.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Feb 2023 16:32:28 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 4C85F1140F9C; Wed, 8 Feb 2023 11:02:26 +1030 (ACDT) Date: Wed, 8 Feb 2023 11:02:26 +1030 From: Alan Modra To: "Maciej W. Rozycki" Cc: binutils@sourceware.org, Chenghua Xu Subject: Re: Protect mips_hi16_list from fuzzed debug info Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3027.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Feb 07, 2023 at 02:11:23PM +0000, Maciej W. Rozycki wrote: > On Mon, 6 Feb 2023, Alan Modra wrote: > > > This is another fix for the testcase mentioned in > > https://sourceware.org/pipermail/binutils/2023-February/125915.html > > either of which will stop the addr2line segfault. This one also fixes > > a potential problem when linking corrupted debug info. > > Hmm, from the other message I gather DWARF info is not going to be > processed twice anymore, so why is this change to the MIPS backend also > required? See below. > Also would it be possible to have a MIPS test case for your change? > Orchestrating HI16/LO16 relocations in a debug section should be pretty > straightforward with the use of the `.reloc' pseudo-op. This might help > me understand what is really going on here. I could do that, but my time is limited for mips problems. I'll understand if you say the patch is not worth committing just to cover a potential fuzzed object file segfault. > Also one concern about code proposed itself, see below. > > > @@ -2596,38 +2600,41 @@ _bfd_mips_elf_lo16_reloc (bfd *abfd, arelent *reloc_entry, asymbol *symbol, > [...] > > + if (!tdata->freeze_mips_hi16_list) > > This conditional ought to wrap all the preceding code in the function as > well (including the declaration block), because it's sole purpose is to > retrieve `vallo', which is only used within the `while' loop now placed > under the conditional... OK, done. I'm presuming I don't need to repost the patch. > > + /* Debug info should not contain hi16 or lo16 relocs. If it does > > + then someone is playing fuzzing games. Altering the hi16 list > > + during linking when printing an error message is bad. */ s/an error/a warning/ > And I really cannot extract the meaning of the second sentence here. I > mean I know what it literally means, but that does not really tell me > anything. Why would altering the list be a problem given that we're > bailing out anyway? I'm confused. A number of the error/warning handlers in ldmain.c use %C. This can cause debug info to be parsed for the first time in order to print file/function/line. If one of those warnings is triggered after some hi16 relocs have been processed but before the matching lo16 reloc is handled, *and* the debug info is corrupted with a lo16 reloc, then the mips_hi16_list will be flushed with the result that printing a warning changes linker output. It is also possible that corrupted debug info adds to the hi16 list, with the result that when the linker handles a later lo16 reloc in a text section, ld will segfault accessing mips_hi16.data after the debug buffers have be freed. Is this likely to happen in the real world? No, of course not, but fuzzers keep finding this sort of thing, and the occasional real problem found by the fuzzers is enough that I haven't yet decided to ignore all fuzzing reports. -- Alan Modra Australia Development Lab, IBM