https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81684
Bug ID: 81684 Summary: Out of Memory in demangler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: security-tps at google dot com Target Milestone: --- Created attachment 41909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41909&action=edit binutils docker file Hello GCC team, As part of our fuzzing efforts at Google, we have identified an issue affecting demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git). To reproduce we are attaching a dockerfile to help compiling the project with the LLVM taking advantage of the sanitizers that it offers. Attached is a dockerfile that can be used for reproduction. More information about how to use the dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ TL;DR instructions: mkdir binutils cp Dockerfile /path/to/binutils docker build --no-cache /path/to/binutils docker run -it <image id> (from another terminal, outside the container): docker cp /path/to/attached/reproducer <container id>:/fuzzing/ https://docs.docker.com/engine/reference/commandline/cp/ (back inside the container) /fuzzing/repro.sh /fuzzing/reproducer Alternatively, and depending on the bug, you could use gcc, valgrind or other instrumentation tools to aid in the investigation. The sanitizer error that we encountered is here: ==23== ERROR: libFuzzer: out-of-memory (used: 2369Mb; limit: 2048Mb) To change the out-of-memory limit use -rss_limit_mb=<N> Live Heap Allocations: 11282956931 bytes from 20 allocations; showing top 50% 11280523256 byte(s) (99%) in 1 allocation(s) #0 0x4cd488 in __interceptor_malloc (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488) #1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12 #2 0x50fb7e in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27 #3 0x50e30d in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18 #4 0x50bc20 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14 #5 0x50a99c in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x50847d in LLVMFuzzerTestOneInput /fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20 #7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec) #8 0x52f3bc in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc) Is it expected or reasonable for an input of this size to require over 2GB of memory, or is it possible to add a feature to cap the amount of memory the library will attempt to use to mitigate issues like this? Additionally, do you have any interest in these kinds of reports? We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation. Once you have reproduced the issue, we’d appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to “Google Autofuzz project”. We are also pleased to inform you that your project is eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate integration options (https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md). Don’t hesitate to let us know if you have any questions! Google AutoFuzz Team