https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120334
Bug ID: 120334
Summary: lto plugin doesn't check for excess section size
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Originally reported at https://sourceware.org/bugzilla/show_bug.cgi?id=32978
but I realised it's actually an issue on the GCC LTO plugin side.
---
We had a bug report of a confusing error from ld when building Clang:
```
out of memory allocating 6074313780942294634 bytes after a total of 1159128
bytes
```
The cause was a corrupt libLLVM.so:
```
Starting program: /usr/x86_64-pc-linux-gnu/bin/ld -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/16/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccrYkTIx.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie
-z now /usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../.. -L/lib -L/usr/lib
BuildConfusableTable.cpp.o usr/lib/llvm/18/lib64/libLLVM.so.18.1 -v -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/16/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/crtn.o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
GNU ld (Gentoo 9999 p1) 2.44.50.20250516
out of memory allocating 6074313780942294634 bytes after a total of 1159128
bytes
Breakpoint 2, __GI_exit (status=status@entry=1) at exit.c:147
147 {
(gdb) bt
#0 __GI_exit (status=status@entry=1) at exit.c:147
#1 0x00007ffff77f245e in xexit (code=1) at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/xexit.c:47
#2 xmalloc_failed (size=6074313780942294634) at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/xmalloc.c:139
#3 0x00007ffff77eee2d in xmalloc (size=size@entry=6074313780942294634) at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/xmalloc.c:151
#4 0x00007ffff77f578b in simple_object_elf_find_sections (sobj=0x555555955c60,
pfn=0x7ffff77f5940 <process_symtab>, data=0x7fffffffc910, err=0x7fffffffc904)
at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/simple-object-elf.c:613
#5 0x00007ffff77f44df in simple_object_find_sections (sobj=<optimized out>,
pfn=0x7ffff77f5940 <process_symtab>, data=0x7fffffffc910, err=0x7fffffffc904)
at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/simple-object.c:199
#6 claim_file_handler_v2 (file=0x7fffffffca10, can_be_claimed=0x7fffffffca0c,
known_used=1) at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/lto-plugin/lto-plugin.c:1262
#7 0x0000555555682afd in plugin_call_claim_file (file=0x7fffffffca10,
claimed=0x7fffffffca0c, claim_file_handler_v2=<synthetic pointer>,
known_used=true)
at /usr/src/debug/sys-devel/binutils-9999/binutils/ld/plugin.c:1185
#8 plugin_object_p (ibfd=0x5555558c5000, known_used=true) at
/usr/src/debug/sys-devel/binutils-9999/binutils/ld/plugin.c:1279
#9 0x00007ffff7812d5a in bfd_check_format_matches (abfd=0x5555558c5000,
format=format@entry=bfd_object, matching=matching@entry=0x0)
at /usr/src/debug/sys-devel/binutils-9999/binutils/bfd/format.c:583
#10 0x00007ffff78139a7 in bfd_check_format (abfd=<optimized out>,
format=format@entry=bfd_object) at
/usr/src/debug/sys-devel/binutils-9999/binutils/bfd/format.c:105
#11 0x0000555555681ea7 in ldfile_try_open_bfd (attempt=0x7fffffffdb41
"usr/lib/llvm/18/lib64/libLLVM.so.18.1", entry=entry@entry=0x555555875200)
at /usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldfile.c:533
#12 0x00005555556920a7 in ldfile_open_file (entry=entry@entry=0x555555875200)
at /usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldfile.c:619
#13 0x0000555555691d4e in load_symbols (entry=0x555555875200,
place=0x7fffffffce50) at
/usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldlang.c:3095
#14 0x000055555568115c in open_input_bfds.constprop.0 (s=0x555555875200,
os=0x5555558765d0, os@entry=0x0, mode=OPEN_BFD_NORMAL)
at /usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldlang.c:3731
#15 0x000055555567b960 in lang_process () at
/usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldlang.c:8322
#16 0x0000555555689e30 in main (argc=42, argv=0x7fffffffd258) at
/usr/src/debug/sys-devel/binutils-9999/binutils/ld/ldmain.c:882
```
```
(gdb) frame 4
#4 0x00007ffff77f578b in simple_object_elf_find_sections (sobj=0x555555955c60,
pfn=0x7ffff77f5940 <process_symtab>, data=0x7fffffffc910, err=0x7fffffffc904)
at
/usr/src/debug/sys-devel/gcc-16.0.9999/gcc-16.0.9999/libiberty/simple-object-elf.c:613
613 names = XNEWVEC (unsigned char, name_size);
(gdb) p name_size
$1 = 6074313780942294634
```
Should we have a cap on name_size for some insane size? mold gives:
```
mold: fatal: usr/lib/llvm/18/lib64/libLLVM.so.18.1: section header is out of
range: 5004190175082407278
```
