[Bug binutils/24100] New: An unsigned integer overflow which may cause huge amount of heap allocation
https://sourceware.org/bugzilla/show_bug.cgi?id=24100
Bug ID: 24100
Summary: An unsigned integer overflow which may cause huge
amount of heap allocation
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: poppeter1982 at gmail dot com
Target Milestone: ---
Hi There
Peng Li and Shengjian Guo at Baidu X-Lab discovered a suspicious unsigned
integer overflow which may lead to a huge amount of memory allocation in heap.
In get_dynamic_data of readelf.c of version 2.31.51.20190117
static bfd_vma *
get_dynamic_data (Filedata * filedata, bfd_size_type number, unsigned int
ent_size)
{
...
if (ent_size * number > filedata->file_size)
{
error (_("Invalid number of dynamic entries: %s\n"),
bfd_vmatoa ("u", number));
return NULL;
}
e_data = (unsigned char *) cmalloc ((size_t) number, ent_size);
...
}
If you compile readelf with -fsanitize=unsigned-integer-overflow and run
./readelf -a input, it is reported that readelf.c:11251:16: runtime error:
unsigned integer overflow: 8 * 5765762010251921410 cannot be represented in
type 'unsigned long'. With regards to this input, the wrap around result of
ent_size * number is still greater than file_size (2413), so the variable
"number" that is 5765762010251921410 does not flow into cmalloc operation.
However, let's think about the case where number is still a huge number and
8*huge_number is less than file_size, then consequently a huge amount of memory
will be allocated in heap. One possible solution to resolve the multiplication
overflow is to use division instead, for example, the conditional is changed to
if (ent_size > filedata->file_size/number).
If you have any questions about this issue and input in the attachment, please
let me know.
Thanks
Peng
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24100] An unsigned integer overflow which may cause huge amount of heap allocation in readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24100 poppeter1982 at gmail dot com changed: What|Removed |Added Summary|An unsigned integer |An unsigned integer |overflow which may cause|overflow which may cause |huge amount of heap |huge amount of heap |allocation |allocation in readelf -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24098] New: readelf gets SegFault on crafted input that may cause DoS
https://sourceware.org/bugzilla/show_bug.cgi?id=24098 Bug ID: 24098 Summary: readelf gets SegFault on crafted input that may cause DoS Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: PeterRong96 at gmail dot com Target Milestone: --- Created attachment 11541 --> https://sourceware.org/bugzilla/attachment.cgi?id=11541=edit 3 files that led to crash. By fuzzing readelf, we have crafted three files that produce SegFaults, and it might cause DoS vulnerabilities. Crash site: readelf.c:8028 8024: relname = elf_hppa_reloc_type (get_reloc_type ( filedata, rp->r_info)); ... 8028: if (! const_strneq (relname, "R_PARISC_SEGREL")) In line 8024 relname become NULL when feeded with crafted data. Doing strncmp later on line 8028 on a NULL pointer it is invalid. Crash cause: According to definition in include/hppa.h:110-496 and include/reloc-marcos.h:95-127, when given "the relocation is not recognised, NULL is returned."(citing comment from include/reloc-marcos.h:97). Below is a stack printed using gdb. #0 __strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101 No locals. #1 0x556336f2 in slurp_hppa_unwind_table (filedata=, sec=, aux=) at readelf.c:8028 nentries = size = seg = table = tp = relsec = nrelas = rela = relname = 0x0 sym = i = rp = tep = tmp1 = tmp2 = #2 hppa_process_unwind (filedata=) at readelf.c:8115 num_unwind = res = 0 i = sec = unwsec = aux = strsec = #3 0x555a8135 in process_unwind (filedata=) at readelf.c:9253 handlers = #4 process_object (filedata=) at readelf.c:18822 res = 0 i = 31 separates = #5 0x55577866 in process_file (file_name=) at readelf.c:19259 armag = "\177ELF\002\003\001" ret = 1 statbuf = filedata = #6 main (argc=, argv=) at readelf.c:19318 err = 0 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 --- Comment #29 from Luke Kenneth Casson Leighton --- i tried the same massive 6GB link as was carried out under an i386 (32-bit) chroot. this time both of them succeeded. ld-bfd with --no-keep-memory succeeded as before with a warning, using only 280mb during the linker phase (the number of functions called had been increase: python evil_linker_torture.py 800 400 20 800) ld-gold *also* succeeded, once again requiring 6.5 GB of resident RAM to carry out the link [on a 64-bit system]. it would appear that the options recommended to use in comment #25 do not prevent ld-gold from mallocing the full memory of the full size of the target executable. consequently, attempting to link a 6 GB executable on a 32-bit system (with an obvious limit of 4GB) is guaranteed to fail. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23466] Issues with Windows reproducible builds starting with commit 13e570f80cbfb299a8858ce6830e91a6cb40ab7b
https://sourceware.org/bugzilla/show_bug.cgi?id=23466 Nicolas Vigier changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Nicolas Vigier --- After investigating the issue, it seems that what is causing our build to be unreproductible is that an .a archive that we use to link a dll is containing .o files in random order. It seems that before commit 13e570f80cbfb299a8858ce6830e91a6cb40ab7b the order of .o files inside an .a archive did not matter, but not anymore. During our build, we are building gcc 6.4.0, which is using an old version of libtool, which is adding the .o files inside libstdc++.a in a nondeterministic order. We can easily patch libtool to sort the .o files when adding them to an .a archive, which is solving the issue for us. I don't know if ld giving different output depending on the order of .o files is a bug or not. As we can easily solve this issue at the gcc/libtool level, I am closing this ticket, but feel free to reopen it if you think otherwise. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 --- Comment #28 from Luke Kenneth Casson Leighton --- (In reply to Luke Kenneth Casson Leighton from comment #27) > ld-bfd - with "--no-keep-memory" - only requires 750 MB of resident RAM, to > link the exact same 6GB executable. (and aside from a warning "i686-linux-gnu-ld.bfd: warning: cannot find entry symbol _start; defaulting to 08048094", succeeded. correction: i had added one too many "0s" onto the evil python command. however after correction, the results are exactly the same: debian-i386-chroot$ python evil_linker_torture.py 80 40 20 8000 * make maing FAILs * make main SUCCEEDs (except only using 85mb for the linker phase) so this is far more complex and involved than it first appears. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 Luke Kenneth Casson Leighton changed: What|Removed |Added Attachment #11522|0 |1 is obsolete|| --- Comment #27 from Luke Kenneth Casson Leighton --- Created attachment 11540 --> https://sourceware.org/bugzilla/attachment.cgi?id=11540=edit updated version of liinker torturer i decided to run an i386 debian chroot, using a variant of evil_linker_torture.py and running these options: $python evil_linker_torture.py 80 40 20 8 the results of the link (an error) are below: $ make -j8 maing i686-linux-gnu-ld.gold src0.o src1.o src10.o src11.o src12.o src13.o src14.o src15.o src16.o src17.o src18.o src19.o src2.o src20.o src21.o src22.o src23.o src24.o src25.o src26.o src27.o src28.o src29.o src3.o src30.o src31.o src32.o src33.o src34.o src35.o src36.o src37.o src38.o src39.o src4.o src40.o src41.o src42.o src43.o src44.o src45.o src46.o src47.o src48.o src49.o src5.o src50.o src51.o src52.o src53.o src54.o src55.o src56.o src57.o src58.o src59.o src6.o src60.o src61.o src62.o src63.o src64.o src65.o src66.o src67.o src68.o src69.o src7.o src70.o src71.o src72.o src73.o src74.o src75.o src76.o src77.o src78.o src79.o src8.o src9.o -g -g -g --no-mmap-output-file --no-map-whole-files --no-keep-files-mapped --no-keep-memory -o maing i686-linux-gnu-ld.gold: internal error in convert_types, at ../../gold/gold.h:192 this is with the following version: $ gold --version GNU gold (GNU Binutils for Debian 2.28) 1.14 the most likely reason is that the size of the executable is over 6GB, and a 32-bit version of gold cannot cope. when run on 64-bit it does fine, the only strange thing being that it still requires 7GB of resident RAM to link a 6GB executable. ld-bfd - with "--no-keep-memory" - only requires 750 MB of resident RAM, to link the exact same 6GB executable. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
