Bug 32643 - ld SEGV (illegal read access) in _bfd_elf_gc_mark_rsec (bfd/elflink.c:14031:11) with --gc-sections --no-print-gc-sections -w options
Summary: ld SEGV (illegal read access) in _bfd_elf_gc_mark_rsec (bfd/elflink.c:14031:1...
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.43
: P2 normal
Target Milestone: ---
Assignee: Nick Clifton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-05 13:12 UTC by 孙文举
Modified: 2025-02-12 14:07 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2025-02-05 00:00:00
Project(s) to access:
ssh public key:


Attachments
poc (2.54 KB, application/x-object)
2025-02-05 13:12 UTC, 孙文举
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 孙文举 2025-02-05 13:12:52 UTC
Created attachment 15918 [details]
poc

**Description**
A segv can occur in ld (part of binutils 2.43) when using the  --gc-sections --no-print-gc-sections -w  options with a specially crafted input file. This issue leads to memory corruption (illegal memory read access) and crashes.

**Affected Version**
GNU ld (GNU Binutils) 2.43

**Steps to Reproduce**

Build binutils 2.43 with AddressSanitizer (e.g., CFLAGS="-g -fsanitize=address" ./configure && make -j).
Run the following command:
./binutils-2.43/bins/bin/ld --gc-sections --no-print-gc-sections -w /tmp/poc

./binutils-2.43/bins/bin/ld: /tmp/poc symbol number 45 references nonexistent SHT_SYMTAB_SHNDX section
AddressSanitizer:DEADLYSIGNAL
=================================================================
==486332==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x55735179a445 bp 0x7ffdcb9d5190 sp 0x7ffdcb9d4fb0 T0)
==486332==The signal is caused by a READ memory access.
==486332==Hint: address points to the zero page.
    #0 0x55735179a445 in _bfd_elf_gc_mark_rsec ./binutils-2.43/bfd/elflink.c:14031:11
    #1 0x55735179ac90 in _bfd_elf_gc_mark_reloc ./binutils-2.43/bfd/elflink.c:14091:10
    #2 0x55735179b474 in _bfd_elf_gc_mark ./binutils-2.43/bfd/elflink.c:14143:11
    #3 0x55735179ae30 in _bfd_elf_gc_mark_reloc ./binutils-2.43/bfd/elflink.c:14099:14
    #4 0x55735179b474 in _bfd_elf_gc_mark ./binutils-2.43/bfd/elflink.c:14143:11
    #5 0x55735179ae30 in _bfd_elf_gc_mark_reloc ./binutils-2.43/bfd/elflink.c:14099:14
    #6 0x55735179b474 in _bfd_elf_gc_mark ./binutils-2.43/bfd/elflink.c:14143:11
    #7 0x5573517a08fc in bfd_elf_gc_sections ./binutils-2.43/bfd/elflink.c:14719:11
    #8 0x557351549b0d in lang_gc_sections ./binutils-2.43/ld/ldlang.c:7763:5
    #9 0x55735154378b in lang_process ./binutils-2.43/ld/ldlang.c:8378:3
    #10 0x55735156d34c in main ./binutils-2.43/ld/./ldmain.c:529:3
    #11 0x7fc0629db082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
    #12 0x5573514456bd in _start (./binutils-2.43/bins/bin/ld+0x15a6bd) (BuildId: d9731e405748db264b62c84ded760ba4f068cb0a)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ./binutils-2.43/bfd/elflink.c:14031:11 in _bfd_elf_gc_mark_rsec
==486332==ABORTING

** Env **
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal
Comment 1 Sourceware Commits 2025-02-05 15:43:36 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=931494c9a89558acb36a03a340c01726545eef24

commit 931494c9a89558acb36a03a340c01726545eef24
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Feb 5 15:43:04 2025 +0000

    Add even more checks for corrupt input when processing relocations for ELF files.
    
    PR 32643
Comment 2 Nick Clifton 2025-02-05 15:45:28 UTC
Fixed.

This was similar to the other recent filings - assumptions in the linker's reloc processing code that the input was correct.

With this patch I have tried to cover other cases where similar assumptions are made, so maybe the patch will fix more than just this one PR.
Comment 3 Michael Matz 2025-02-12 14:07:25 UTC
(In reply to Nick Clifton from comment #2)
> With this patch I have tried to cover other cases where similar assumptions
> are made, so maybe the patch will fix more than just this one PR.

While hardening the code is perhaps a reasonable idea (if not too expensive),
isn't the actual problem rather that -w disabled exit-on-error (an error message
is clearly given here), like Alan fixed in
  https://sourceware.org/bugzilla/show_bug.cgi?id=32603
?  I.e. why are we even running the GC section code when an input file is invalid?