From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 78A2B3858D39 for ; Thu, 9 Feb 2023 00:29:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78A2B3858D39 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-x62b.google.com with SMTP id v23so1143022plo.1 for ; Wed, 08 Feb 2023 16:29:54 -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=oMs+Yi/7QjSfikV2r9azpPoNXYsnoag+I+Nt/f5Y0Ec=; b=RS2i93oTniRuMRtORzuvNHfkZidCJqJHZNPPNL57EePU4wx6gB/c7vWc4se0NnViAP hfKmH7gfWq6eMg4US35uDFRUj7dVI2h5jb0EWLNAVZZ+Wo/W98iH7mRkrUX7JDXy0f81 BjHqIp79Tp4nGdFXchefafVrOyMOAVYeaF2wdk043SVLxLjHkK/MyscLk/ikW5z0WINT ECsebaxSoPjafd8/X61kbgg1CVqP4oyZeUb1jjknhlk2hG5X4ezSexJMaq0w3Aw9IOhq B0jObglwxJ69NSsQcxWm3U4Sh1Tp+N1KMeoaHCvtVWgy9GVU86w3dZ2BAeLyddSCnbt4 xlbw== 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=oMs+Yi/7QjSfikV2r9azpPoNXYsnoag+I+Nt/f5Y0Ec=; b=vICyyB5LixfrJFXmSJVVHoBqAZXpVHnF2JRqj+aJy0OEg6eFOAU8q0d+UzBa/D9Eeo IGV5eo9TRbm4vIy7zKZe/lvgcbaEHFQS189qVYkWLboA7ThRu9PGm8TPVI7dWFnFLmRg VkshnVWODStKtgA2LeUe8+ZcwI4XFEiYVMPwlJskcTgaYcW+uWU2fy4ywyNOd1acR4GN V9tfKTHExcArDWIvak4ecMU60xDgpT6K1hUXNcxW9TOa5fV9cTF4jqWtcInhAC1rXieR gZDDWr+iRfodYKYUYd4IvZRFvKe8CT5iHKuOE698jCSrh/wQkLAZ/Il+62kqTZGBFtG+ KhLA== X-Gm-Message-State: AO0yUKW4KXZf+P8sxGbEG6sEWFEqyaAXVmmRa6JR+9e1tRUc8OQy6jKS 8WB+WNr5L5gxOq4Bt08bf94= X-Google-Smtp-Source: AK7set+cHsK6aVmbhRQB0uUeg7eUKwQ95TsksCRNO5qZTI8Tu6jf60N4jzao1Tj4C2XOsDszZcXqgw== X-Received: by 2002:a17:902:db07:b0:196:13cd:a49 with SMTP id m7-20020a170902db0700b0019613cd0a49mr9932377plx.27.1675902593579; Wed, 08 Feb 2023 16:29:53 -0800 (PST) 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 k20-20020a170902ba9400b00192c5327021sm48499pls.200.2023.02.08.16.29.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Feb 2023 16:29:53 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id BC53F1141D35; Thu, 9 Feb 2023 10:59:50 +1030 (ACDT) Date: Thu, 9 Feb 2023 10:59:50 +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=-3029.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 Wed, Feb 08, 2023 at 11:28:08PM +0000, Maciej W. Rozycki wrote: > On Wed, 8 Feb 2023, Alan Modra wrote: > > 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. > > Hmm, I find it an interesting general phenomenon. What it means the > order sections are processed in can change depending on whether a warning > has been issued in the course or not. Is it not a problem in the first > place? Shouldn't we give priority to debugs sections and parse them first > then before moving on to the other sections? The normal linker processing of sections occurs as usual. Parsing of the debug info is separate to this, relocations being applied to .debug_info by bfd_simple_get_relocated_section_contents for the error/warning message. That relocated copy of .debug_info is not used by the linker to produce the output file .debug_info. > > 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. > > OK, but wouldn't these relocs be resolved in the same problematic way > anyway when the turn came to processing debug sections? > > > 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. > > This smells a HI16/LO16 pair processing bug to me by itself. Such pairs > must come from the same relocation section, so any HI16/LO16 relocations > in a relocation section associated with a debug section are not supposed > to influence any such relocations referring to the text section. I think > I need to look into it (though see above as to my availability). If it is really true that hi16/lo16 pairs are always in the same section, then we wouldn't need freeze_mips_hi16_list. Instead it would be much better to attach the list to mips_elf_section_data. I wasn't sure enough to do that, given things like gcc's hot/cold section partitioning, when I moved the mip_hi16_list to be per-bfd. -- Alan Modra Australia Development Lab, IBM