bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/32641] ld SEGV (illegal read access) in _bfd_x86_elf_check_reloc


From: nickc at redhat dot com
Subject: [Bug ld/32641] ld SEGV (illegal read access) in _bfd_x86_elf_check_relocs (bfd/elfxx-x86.c:980:19) with -w option
Date: Wed, 05 Feb 2025 14:32:44 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=32641

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Fixed.

This was another case where the linker's code was assuming that relocations and
symbols were well formed and not checking for possible corruption.

Note - even with this patch applied, I still saw a sanitizer failure:

=================================================================
==3041740==ERROR: AddressSanitizer: requested allocation size 0x490000000030
(0x490000001030 after adjustments for alignment, red zones etc.) exceeds
maximum supported size of 0x10000000000 (thread T0)
    #0 0x14d83aac2897 in malloc (/lib64/libasan.so.8+0xc2897) (BuildId:
0505b45e5a5d9a6c8ecb1d529aaaf13cd21fbe4e)
    #1 0x967506 in bfd_malloc
/work/sources/binutils/upstream/current/bfd/libbfd.c:291
    #2 0xa9af43 in bfd_elf_final_link
/work/sources/binutils/upstream/current/bfd/elflink.c:13030
    #3 0x45d86a in ldwrite
/work/sources/binutils/upstream/current/ld/ldwrite.c:550
    #4 0x45662f in main /work/sources/binutils/upstream/current/ld/ldmain.c:560
    #5 0x14d83a74f247 in __libc_start_call_main (/lib64/libc.so.6+0x3247)
(BuildId: 515c33a35f41020661fea8ac4eb995e26ccd6b00)
    #6 0x14d83a74f30a in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x330a) (BuildId: 515c33a35f41020661fea8ac4eb995e26ccd6b00)
    #7 0x401c34 in _start 

This however is a false positive, since it is reporting that the requested
output size of the linked binary is too big.  The linker code does handle this
situation correctly however, so I added "allocator_may_return_null=1" to my
sanitizer options in order to stop this error.  With that option enabled the
link no longer triggers any sanitization issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]