Bug 29006 - dll_symname use after free
Summary: dll_symname use after free
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.38
: P2 normal
Target Milestone: ---
Assignee: Alan Modra
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-29 11:36 UTC by Sandro Mani
Modified: 2022-05-13 11:31 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2022-05-11 00:00:00


Attachments
Proposed Patch (875 bytes, patch)
2022-03-31 15:27 UTC, Nick Clifton
Details | Diff
another patch (3.17 KB, patch)
2022-05-11 13:17 UTC, Alan Modra
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sandro Mani 2022-03-29 11:36:08 UTC
I'm trying to build mingw-llvm-1.14.0 [1] with mingw-binutils-2.38-1.fc37.x86_64, mingw-gcc-12.0.1-1.fc37.x86_64.

[1] https://smani.fedorapeople.org/mingw-llvm-14.0.0-1.fc37.src.rpm

Linking llvm-cvtres.exe fails with 

malloc(): invalid size (unsorted)
collect2: fatal error: ld terminated with signal 6 [Aborted], core dumped
compilation terminated.

Reduced command line:

$ i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp

Note: Error only appears if both -fstack-protector and -lssp are present. Appears to be a regression since mingw-binutils-2.37-5.fc37.

Valgrind says:

$ valgrind i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp
==794194== Memcheck, a memory error detector
==794194== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794194== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==794194== Command: i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp
==794194== 
malloc(): invalid size (unsorted)
collect2: fatal error: ld terminated with signal 6 [Aborted], core dumped
compilation terminated.
[sandro@PC4 llvm-cvtres]$ valgrind --trace-children=yes i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp
==794496== Memcheck, a memory error detector
==794496== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794496== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==794496== Command: i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp
==794496== 
==794496== Memcheck, a memory error detector
==794496== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794496== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==794496== Command: /usr/bin/i686-w64-mingw32-g++ -fstack-protector -lssp -Wl,--whole-archive CMakeFiles/llvm-cvtres.dir/objects.a -Wl,--no-whole-archive -o ../../bin/llvm-cvtres.exe @CMakeFiles/llvm-cvtres.dir/linklibs.rsp
==794496== 
==794497== Memcheck, a memory error detector
==794497== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794497== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==794497== Command: /usr/libexec/gcc/i686-w64-mingw32/12.0.1/collect2 -plugin /usr/libexec/gcc/i686-w64-mingw32/12.0.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/12.0.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccimcNFc.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 --sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -u ___register_frame_info -u ___deregister_frame_info -o ../../bin/llvm-cvtres.exe /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o /usr/lib/gcc/i686-w64-mingw32/12.0.1/crtbegin.o -L/usr/lib/gcc/i686-w64-mingw32/12.0.1 -L/usr/lib/gcc/i686-w64-mingw32/12.0.1/../../../../i686-w64-mingw32/lib/../lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib -L/usr/lib/gcc/i686-w64-mingw32/12.0.1/../../../../i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib @/tmp/ccqLXUyr -lssp_nonshared -lssp -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 /usr/lib/gcc/i686-w64-mingw32/12.0.1/crtend.o
==794497== 
==794498== Memcheck, a memory error detector
==794498== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794498== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==794498== Command: /usr/lib/gcc/i686-w64-mingw32/12.0.1/../../../../i686-w64-mingw32/bin/ld @/tmp/cc0mZqz8
==794498== 
==794498== Invalid read of size 1
==794498==    at 0x484A5F6: strlen (vg_replace_strmem.c:494)
==794498==    by 0x48E8AA7: __vfprintf_internal (vfprintf-internal.c:1517)
==794498==    by 0x48F2A1A: __vsprintf_internal (iovsprintf.c:96)
==794498==    by 0x49961C0: __sprintf_chk (sprintf_chk.c:40)
==794498==    by 0x14DB2B: UnknownInlinedFun (stdio2.h:38)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2644)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2810)
==794498==    by 0x14DB2B: make_import_fixup.lto_priv.0 (ei386pe.c:1123)
==794498==    by 0x1FD524: pe_walk_relocs.constprop.0 (pe-dll.c:1349)
==794498==    by 0x15563E: UnknownInlinedFun (pe-dll.c:1497)
==794498==    by 0x15563E: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1400)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Address 0x6b606a0 is 0 bytes inside a block of size 13 free'd
==794498==    at 0x48470E4: free (vg_replace_malloc.c:872)
==794498==    by 0x153EF5: UnknownInlinedFun (pe-dll.c:3296)
==794498==    by 0x153EF5: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Block was alloc'd at
==794498==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==794498==    by 0x1F7E7D: UnknownInlinedFun (xmalloc.c:149)
==794498==    by 0x1F7E7D: xstrdup (xstrdup.c:34)
==794498==    by 0x153B5B: UnknownInlinedFun (pe-dll.c:3206)
==794498==    by 0x153B5B: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498== 
==794498== Invalid read of size 1
==794498==    at 0x484A604: strlen (vg_replace_strmem.c:494)
==794498==    by 0x48E8AA7: __vfprintf_internal (vfprintf-internal.c:1517)
==794498==    by 0x48F2A1A: __vsprintf_internal (iovsprintf.c:96)
==794498==    by 0x49961C0: __sprintf_chk (sprintf_chk.c:40)
==794498==    by 0x14DB2B: UnknownInlinedFun (stdio2.h:38)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2644)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2810)
==794498==    by 0x14DB2B: make_import_fixup.lto_priv.0 (ei386pe.c:1123)
==794498==    by 0x1FD524: pe_walk_relocs.constprop.0 (pe-dll.c:1349)
==794498==    by 0x15563E: UnknownInlinedFun (pe-dll.c:1497)
==794498==    by 0x15563E: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1400)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Address 0x6b606a1 is 1 bytes inside a block of size 13 free'd
==794498==    at 0x48470E4: free (vg_replace_malloc.c:872)
==794498==    by 0x153EF5: UnknownInlinedFun (pe-dll.c:3296)
==794498==    by 0x153EF5: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Block was alloc'd at
==794498==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==794498==    by 0x1F7E7D: UnknownInlinedFun (xmalloc.c:149)
==794498==    by 0x1F7E7D: xstrdup (xstrdup.c:34)
==794498==    by 0x153B5B: UnknownInlinedFun (pe-dll.c:3206)
==794498==    by 0x153B5B: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498== 
==794498== Invalid read of size 1
==794498==    at 0x48FDC80: _IO_default_xsputn (genops.c:394)
==794498==    by 0x48FDC80: _IO_default_xsputn (genops.c:370)
==794498==    by 0x48E894E: outstring_func (vfprintf-internal.c:239)
==794498==    by 0x48E894E: __vfprintf_internal (vfprintf-internal.c:1517)
==794498==    by 0x48F2A1A: __vsprintf_internal (iovsprintf.c:96)
==794498==    by 0x49961C0: __sprintf_chk (sprintf_chk.c:40)
==794498==    by 0x14DB2B: UnknownInlinedFun (stdio2.h:38)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2644)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2810)
==794498==    by 0x14DB2B: make_import_fixup.lto_priv.0 (ei386pe.c:1123)
==794498==    by 0x1FD524: pe_walk_relocs.constprop.0 (pe-dll.c:1349)
==794498==    by 0x15563E: UnknownInlinedFun (pe-dll.c:1497)
==794498==    by 0x15563E: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1400)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Address 0x6b606a0 is 0 bytes inside a block of size 13 free'd
==794498==    at 0x48470E4: free (vg_replace_malloc.c:872)
==794498==    by 0x153EF5: UnknownInlinedFun (pe-dll.c:3296)
==794498==    by 0x153EF5: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Block was alloc'd at
==794498==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==794498==    by 0x1F7E7D: UnknownInlinedFun (xmalloc.c:149)
==794498==    by 0x1F7E7D: xstrdup (xstrdup.c:34)
==794498==    by 0x153B5B: UnknownInlinedFun (pe-dll.c:3206)
==794498==    by 0x153B5B: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498== 
==794498== Invalid read of size 1
==794498==    at 0x48FDC8F: _IO_default_xsputn (genops.c:393)
==794498==    by 0x48FDC8F: _IO_default_xsputn (genops.c:370)
==794498==    by 0x48E894E: outstring_func (vfprintf-internal.c:239)
==794498==    by 0x48E894E: __vfprintf_internal (vfprintf-internal.c:1517)
==794498==    by 0x48F2A1A: __vsprintf_internal (iovsprintf.c:96)
==794498==    by 0x49961C0: __sprintf_chk (sprintf_chk.c:40)
==794498==    by 0x14DB2B: UnknownInlinedFun (stdio2.h:38)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2644)
==794498==    by 0x14DB2B: UnknownInlinedFun (pe-dll.c:2810)
==794498==    by 0x14DB2B: make_import_fixup.lto_priv.0 (ei386pe.c:1123)
==794498==    by 0x1FD524: pe_walk_relocs.constprop.0 (pe-dll.c:1349)
==794498==    by 0x15563E: UnknownInlinedFun (pe-dll.c:1497)
==794498==    by 0x15563E: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1400)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Address 0x6b606a2 is 2 bytes inside a block of size 13 free'd
==794498==    at 0x48470E4: free (vg_replace_malloc.c:872)
==794498==    by 0x153EF5: UnknownInlinedFun (pe-dll.c:3296)
==794498==    by 0x153EF5: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498==  Block was alloc'd at
==794498==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==794498==    by 0x1F7E7D: UnknownInlinedFun (xmalloc.c:149)
==794498==    by 0x1F7E7D: xstrdup (xstrdup.c:34)
==794498==    by 0x153B5B: UnknownInlinedFun (pe-dll.c:3206)
==794498==    by 0x153B5B: gld_i386pe_after_open.lto_priv.0 (ei386pe.c:1397)
==794498==    by 0x13F3E5: UnknownInlinedFun (ldemul.c:65)
==794498==    by 0x13F3E5: lang_process (ldlang.c:8205)
==794498==    by 0x12F480: main (ldmain.c:497)
==794498== 
==794498== 
==794498== HEAP SUMMARY:
==794498==     in use at exit: 26,268,866 bytes in 3,907 blocks
==794498==   total heap usage: 12,645 allocs, 8,738 frees, 35,292,332 bytes allocated
==794498== 
==794498== LEAK SUMMARY:
==794498==    definitely lost: 63,621 bytes in 460 blocks
==794498==    indirectly lost: 4,548 bytes in 27 blocks
==794498==      possibly lost: 320 bytes in 1 blocks
==794498==    still reachable: 26,200,377 bytes in 3,419 blocks
==794498==         suppressed: 0 bytes in 0 blocks
==794498== Rerun with --leak-check=full to see details of leaked memory
==794498== 
==794498== For lists of detected and suppressed errors, rerun with: -s
==794498== ERROR SUMMARY: 325 errors from 4 contexts (suppressed: 0 from 0)
==794497== 
==794497== HEAP SUMMARY:
==794497==     in use at exit: 19,244 bytes in 142 blocks
==794497==   total heap usage: 172 allocs, 30 frees, 104,420 bytes allocated
==794497== 
==794497== LEAK SUMMARY:
==794497==    definitely lost: 3,680 bytes in 16 blocks
==794497==    indirectly lost: 1,987 bytes in 82 blocks
==794497==      possibly lost: 0 bytes in 0 blocks
==794497==    still reachable: 13,577 bytes in 44 blocks
==794497==         suppressed: 0 bytes in 0 blocks
==794497== Rerun with --leak-check=full to see details of leaked memory
==794497== 
==794497== For lists of detected and suppressed errors, rerun with: -s
==794497== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==794496== 
==794496== HEAP SUMMARY:
==794496==     in use at exit: 102,866 bytes in 108 blocks
==794496==   total heap usage: 334 allocs, 226 frees, 228,758 bytes allocated
==794496== 
==794496== LEAK SUMMARY:
==794496==    definitely lost: 8,730 bytes in 24 blocks
==794496==    indirectly lost: 158 bytes in 15 blocks
==794496==      possibly lost: 43 bytes in 2 blocks
==794496==    still reachable: 93,935 bytes in 67 blocks
==794496==         suppressed: 0 bytes in 0 blocks
==794496== Rerun with --leak-check=full to see details of leaked memory
==794496== 
==794496== For lists of detected and suppressed errors, rerun with: -s
==794496== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Comment 1 Nick Clifton 2022-03-31 15:27:23 UTC
Created attachment 14045 [details]
Proposed Patch

Hi Sandro,

  Are you able to try out a patch ?

  I have uploaded a possible fix, based upon the backtrace in the log you supplied, but I do not have a suitable environment to run the test for myself...

Cheers
  Nick
Comment 2 Sandro Mani 2022-04-26 13:58:26 UTC
Hi Nick, sorry for the late reply, I missed your comment! Just applied to mingw-binutils in Fedora and mingw-llvm is now building fine, thanks!
Comment 3 Sourceware Commits 2022-04-27 07:35:51 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

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

commit 639d467b08f2b581a911dc24f67e8c77a3a05e9f
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Apr 27 08:35:18 2022 +0100

    Fix potential buffer overruns when creating DLLs.
    
            PR 29006
            * pe-dll.c (make_head): Use asprintf to allocate and populate a
            buffer containing the temporary name.
            (make_tail, make_one, make_singleton_name_thunk): Likewise.
            (make_import_fixup_mark, make_import_fixup_entry): Likewise.
            (make_runtime_pseudo_reloc): Likewise.
            (pe_create_runtime_relocator_reference): Likewise.
Comment 4 Nick Clifton 2022-04-27 07:38:28 UTC
Patch applied.
Comment 5 Roland Schwingel 2022-05-11 12:06:58 UTC
Hi...

I maybe have the same or very similar problem. I already have applied the patch to my binutils 2.38 but it still has the same problem.

See here: https://sourceware.org/pipermail/binutils/2022-May/120773.html

the most vital part - the valgrind output:

==23381==
GNU ld (GNU Binutils) 2.38
==23381== Invalid read of size 1
==23381==    at 0x508B434: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x50B83A0: _IO_default_xsputn (in /lib64/libc-2.17.so)
==23381==    by 0x508B472: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x50B83AE: _IO_default_xsputn (in /lib64/libc-2.17.so)
==23381==    by 0x508B472: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==  Address 0x95e2502 is 2 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x508B434: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4436C3: pe_create_runtime_relocator_reference 
(pe-dll.c:2754)
==23381==    by 0x443AD1: pep_create_import_fixup (pe-dll.c:2844)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381==
==23381== HEAP SUMMARY:
==23381==     in use at exit: 83,040,828 bytes in 25,511 blocks
==23381==   total heap usage: 96,735 allocs, 71,224 frees, 122,050,867 
bytes allocated
==23381==
==23381== LEAK SUMMARY:
==23381==    definitely lost: 2,432,172 bytes in 1,940 blocks
==23381==    indirectly lost: 194,424 bytes in 1,075 blocks
==23381==      possibly lost: 0 bytes in 0 blocks
==23381==    still reachable: 80,414,232 bytes in 22,496 blocks
==23381==         suppressed: 0 bytes in 0 blocks
==23381== Rerun with --leak-check=full to see details of leaked memory
==23381==
==23381== For lists of detected and suppressed errors, rerun with: -s
==23381== ERROR SUMMARY: 19110 errors from 4 contexts (suppressed: 0 from 

Thanks for help
Comment 6 Nick Clifton 2022-05-11 13:12:25 UTC
(In reply to Roland Schwingel from comment #5)

Hi Roland,

> I maybe have the same or very similar problem. I already have applied the
> patch to my binutils 2.38 but it still has the same problem.

No - this is a completely different bug, and a nasty one too.

The issue is that the dll_symname string is used by multiple functions 
in ld/pe-dll.c, but it is only valid whilst the pe_process_import_defs()
function is active.  Unfortunately the code in ld/emultemp/pep.em calls
the function pe_find_data_imports() after pe_process_import_defs has
finished, and this function ends up calling down several layers to a
function that uses dll_symname.

I am not sure at this point, of the correct way to fix this problem.

Whilst I am thinking about it, do you have a test case that I can use
to reproduce the bug ?

Cheers
  Nick
Comment 8 Alan Modra 2022-05-11 13:24:27 UTC
(In reply to Nick Clifton from comment #6)
> No - this is a completely different bug, and a nasty one too.

Very similar backtraces..
Comment 9 Roland Schwingel 2022-05-11 13:32:00 UTC
(In reply to Nick Clifton from comment #6)
> (In reply to Roland Schwingel from comment #5)
> 
> Hi Roland,
> 
> > I maybe have the same or very similar problem. I already have applied the
> > patch to my binutils 2.38 but it still has the same problem.
> 
> No - this is a completely different bug, and a nasty one too.
> 
> The issue is that the dll_symname string is used by multiple functions 
> in ld/pe-dll.c, but it is only valid whilst the pe_process_import_defs()
> function is active.  Unfortunately the code in ld/emultemp/pep.em calls
> the function pe_find_data_imports() after pe_process_import_defs has
> finished, and this function ends up calling down several layers to a
> function that uses dll_symname.
> 
> I am not sure at this point, of the correct way to fix this problem.
> 
> Whilst I am thinking about it, do you have a test case that I can use
> to reproduce the bug ?
> 
> Cheers
>   Nick

Regarding testcase. 

The sources are covered by intellectual property. I cannot send them out.
But I think I could construct a reduction with a bunch of .o and .dll files and than send it to you by personal email. I cannot put it here.

Would this be ok?
Comment 10 Nick Clifton 2022-05-11 14:15:12 UTC
(In reply to Alan Modra from comment #8)

> > No - this is a completely different bug, and a nasty one too. 
> Very similar backtraces..

*sigh* I was thinking that this was a different bug.  I really should have followed the link and checked out the other report first.  


(In reply to Roland Schwingel from comment #9)
 
> > Whilst I am thinking about it, do you have a test case that I can use
> > to reproduce the bug ?

> The sources are covered by intellectual property. I cannot send them out.
> But I think I could construct a reduction with a bunch of .o and .dll files
> and than send it to you by personal email. I cannot put it here.
> 
> Would this be ok?

Not really - I would much prefer a test case that anyone can examine, not
just me.  But it looks like Alan has already researched and possibly fixed 
this problem.  So if you could try out the patch that he has suggested and
let us know if it works, then we should not need a test case at all.

Cheers
  Nick
Comment 11 Roland Schwingel 2022-05-11 14:53:33 UTC
I just gave Alans patch a try. valgrind no longe reports an error! 

Great! 

I have seen that Alans patch is based also on Nicks patch and so had both applied.

In my case it linked now without problems. I tried 3 of about 10 cases where it happens. No problems any more.

Alan's patch is not small. Now I am first rebuilding my whole toolchain on windows and linux and do a regression build of all our code. This will take around 1 day to see whether something new pops up now or not. Followed by a full testcycle of our applications to see whether a dll might be broken now.

I hope and believe this will not happen. I will report here when I am done.

Thanks Alan and Nick for your help!
Comment 12 Sourceware Commits 2022-05-12 11:56:07 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

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

commit 678dc756a5741d278be2e14630bc10d2fb31a22a
Author: Alan Modra <amodra@gmail.com>
Date:   Thu May 12 12:55:20 2022 +0100

    Fix an illegal memory access when creating DLLs.
    
            PR 29006
            * pe-dll.c (dll_name): Delete, replacing with..
            (dll_filename): ..this, moved earlier in file.
            (generate_edata): Delete parameters.  Don't set up dll_name here..
            (pe_process_import_defs): ..instead set up dll_filename and
            dll_symname here before returning.
            (dll_symname_len): Delete write-only variable.
            (pe_dll_generate_implib): Don't set up dll_symname here.
Comment 13 Nick Clifton 2022-05-12 11:57:05 UTC
I have gone ahead and applied Alan's patch.
Comment 14 Roland Schwingel 2022-05-13 11:31:15 UTC
So... I am done with testing so far. I could not find any regressions. All my problems are gone and I have linked ~2000 dlls using patched ld. About 120 I have tried so far. All fine.

Thanks again for your fast reactions!