[Bug demangler/87620] New: NULL deref in iterate_demangle_function (117536819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620 Bug ID: 87620 Summary: NULL deref in iterate_demangle_function (117536819) 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 44843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44843=edit artifacts Hello demangle team, As part of our fuzzing efforts at Google, we have identified an issue affecting binutils (tested with revision * master 673fe0f0a7a0624819f1b4cdc289f43691567e91 from https://sourceware.org/git/binutils-gdb.git). To reproduce, we are attaching a Dockerfile which compiles the project with LLVM, taking advantage of the sanitizers that it offers. More information about how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ Instructions: `unzip artifacts_117536819.zip` `docker build --build-arg SANITIZER=address --tag=autofuzz-binutils-117536819 autofuzz_117536819` `docker run --entrypoint /fuzzing/repro.sh --cap-add=SYS_PTRACE -v $PWD/autofuzz_117536819/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504_min:/tmp/poc autofuzz-binutils-117536819 "" /tmp/poc` `docker run --cap-add=SYS_PTRACE -v $PWD/autofuzz_117536819/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504_min:/tmp/poc -it autofuzz-binutils-117536819` 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: ``` INFO: Seed: 3245898553 INFO: Loaded 0 modules (0 guards): /fuzzing/binutils-gdb/build/demangle_fuzzer: Running 1 inputs 500 time(s) each. Running: /tmp/poc-606ae8a2c7f8322fdfbbb8b89142c457f14d52dd65ae4a05becbc18619e68504 ASAN:DEADLYSIGNAL = ==7==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f3986f88676 bp 0x7ffc1870b420 sp 0x7ffc1870aba8 T0) ==7==The signal is caused by a READ memory access. ==7==Hint: address points to the zero page. #0 0x7f3986f88675 in strlen (/lib/x86_64-linux-gnu/libc.so.6+0x80675) #1 0x476d5c in __interceptor_strlen.part.31 (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x476d5c) #2 0x525619 in work_stuff_copy_to_from /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1345:17 #3 0x52381f in iterate_demangle_function /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2731:3 #4 0x51afe2 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1253:14 #5 0x519f28 in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x5215e2 in demangle_template_value_parm /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2128:12 #7 0x51f238 in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2313:14 #8 0x51d439 in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1628:14 #9 0x523876 in iterate_demangle_function /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2743:14 #10 0x51afe2 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1253:14 #11 0x519f28 in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #12 0x517a1d in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/demangle_fuzzer.cc:11:21 #13 0x54aa3e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x54aa3e) #14 0x53fb8e in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53fb8e) #15 0x544097 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x544097) #16 0x53f8ab in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f8ab) #17 0x7f3986f282e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #18 0x41f479 in _start (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x41f479) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x80675) in strlen ==7==ABORTING ``` 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. Don't hesitate to let us know if you have any questions! Google AutoFuzz Team
[Bug demangler/85660] New: Signed Integer Overflow (79257474)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85660 Bug ID: 85660 Summary: Signed Integer Overflow (79257474) 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 44075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44075=edit proof of concept Hello, As part of our fuzzing efforts at Google, we have identified an issue affecting binutils (tested with revision * master 4e6fe7477a4e9260777cbaa01f70df7ae5f063bb). To reproduce, we are attaching a Dockerfile which compiles the project with LLVM, taking advantage of the sanitizers that it offers. More information about how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ Instructions: `unzip artifacts_79257474.zip` `docker build --build-arg SANITIZER=undefined --tag=autofuzz-binutils-79257474 autofuzz_79257474` `docker run --entrypoint /fuzzing/repro.sh --cap-add=SYS_PTRACE -v $PWD/autofuzz_79257474/poc-7c8bacd8e3b958d37b7a4c80eb649af20e1eae6828f838d518a18781c03c438a_min:/tmp/poc autofuzz-binutils-79257474 "" /tmp/poc` `docker run --cap-add=SYS_PTRACE -v $PWD/autofuzz_79257474/poc-7c8bacd8e3b958d37b7a4c80eb649af20e1eae6828f838d518a18781c03c438a_min:/tmp/poc -it autofuzz-binutils-79257474` 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: ``` INFO: Seed: 1481494163 INFO: Loaded 0 modules (0 guards): /fuzzing/binutils-gdb/build/demangle_fuzzer: Running 1 inputs 500 time(s) each. Running: /tmp/poc-7c8bacd8e3b958d37b7a4c80eb649af20e1eae6828f838d518a18781c03c438a /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3597:10: runtime error: signed integer overflow: 66616 * 10 cannot be represented in type 'int' #0 0x4332c3 in get_count /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3597:10 #1 0x42d0bd in do_type /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3874:12 #2 0x4319f4 in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2300:14 #3 0x43027a in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1628:14 #4 0x42e864 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14 #5 0x42d990 in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x42bf02 in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/demangle_fuzzer.cc:11:21 #7 0x4557ee in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4557ee) #8 0x44a93e in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x44a93e) #9 0x44ee47 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x44ee47) #10 0x44a65b in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x44a65b) #11 0x7f090766c2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #12 0x406a69 in _start (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x406a69) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3597:10 in ``` 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. Don't hesitate to let us know if you have any questions! Google AutoFuzz Team
[Bug demangler/83495] Segmentation Fault - 63915465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83495 Google-Autofuzz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX |--- --- Comment #2 from Google-Autofuzz --- Hmm. We did that, and binutils team pointed us here: https://sourceware.org/bugzilla/show_bug.cgi?id=22609 :) Any suggestions on the best way to proceed? Thanks!
[Bug demangler/83495] New: Segmentation Fault - 63915465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83495 Bug ID: 83495 Summary: Segmentation Fault - 63915465 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 42923 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42923=edit Dockerfile + PoC Hello gcc team, As part of our fuzzing efforts at Google, we have identified an issue affecting binutils (tested with revision * master be62dcaa1771b5f2a47f0cfd78f89828f087efff). To reproduce, we are attaching a Dockerfile which compiles the project with LLVM, taking advantage of the sanitizers that it offers. More information about how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ TL;DR instructions: * `mkdir project` * `cp Dockerfile /path/to/project` * `docker build --no-cache /path/to/project` * `docker run -it image_id_from_docker_build` From another terminal, outside the container: `docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer` (reference: https://docs.docker.com/engine/reference/commandline/cp/) And, 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: ASAN:DEADLYSIGNAL = ==9==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x0051a110 bp 0x7fff56532440 sp 0x7fff56532410 T0) ==9==The signal is caused by a READ memory access. ==9==Hint: address points to the zero page. #0 0x51a10f in d_encoding /fuzzing/binutils-gdb/libiberty/cp-demangle.c:1332:46 #1 0x519dc7 in cplus_demangle_mangled_name /fuzzing/binutils-gdb/libiberty/cp-demangle.c:1230:7 #2 0x51edda in d_demangle_callback /fuzzing/binutils-gdb/libiberty/cp-demangle.c:6242:7 #3 0x51e8c8 in d_demangle /fuzzing/binutils-gdb/libiberty/cp-demangle.c:6293:12 #4 0x51e7db in cplus_demangle_v3 /fuzzing/binutils-gdb/libiberty/cp-demangle.c:6450:10 #5 0x50a81a in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:880:13 #6 0x50847d in LLVMFuzzerTestOneInput /fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20 #7 0x5376ec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x5376ec) #8 0x536eae in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x536eae) #9 0x530d0d in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x530d0d) #10 0x5321df in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x5321df) #11 0x530bbc in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x530bbc) #12 0x7fa7e9b152b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) #13 0x41db69 in _start (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x41db69) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /fuzzing/binutils-gdb/libiberty/cp-demangle.c:1332:46 in d_encoding ==9==ABORTING 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. Don't hesitate to let us know if you have any questions! Google AutoFuzz Team
[Bug demangler/83472] Signed Integer Overflow - 38176028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83472 --- Comment #1 from Google-Autofuzz --- Copy and paste error, sorry for calling you the binutils teams, gcc/demangler team. :)
[Bug demangler/83472] New: Signed Integer Overflow - 38176028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83472 Bug ID: 83472 Summary: Signed Integer Overflow - 38176028 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 42909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42909=edit PoC + Dockerfile Filing here per: https://sourceware.org/bugzilla/show_bug.cgi?id=22610 Hello binutils team, As part of our fuzzing efforts at Google, we have identified an issue affecting binutils (tested with revision * master 79e741920446582bd0e09f3e2b9f899c258efa56). To reproduce, we are attaching a Dockerfile which compiles the project with LLVM, taking advantage of the sanitizers that it offers. More information about how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/ TL;DR instructions: * `mkdir project` * `cp Dockerfile /path/to/project` * `docker build --no-cache /path/to/project` * `docker run -it image_id_from_docker_build` From another terminal, outside the container: `docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer` (reference: https://docs.docker.com/engine/reference/commandline/cp/) And, 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: /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3597:10: runtime error: signed integer overflow: 7 * 10 cannot be represented in type 'int' SUMMARY: AddressSanitizer: undefined-behavior /fuzzing/binutils-gdb/libiberty/cplus-dem.c:3597:10 in 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. Don't hesitate to let us know if you have any questions! Google AutoFuzz Team
[Bug demangler/81684] Out of Memory in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81684 --- Comment #1 from Google-Autofuzz --- Created attachment 41910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41910=edit Demangler PoC
[Bug demangler/81684] New: Out of Memory in demangler
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=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 (from another terminal, outside the container): docker cp /path/to/attached/reproducer :/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= 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
[Bug demangler/81683] Memory leak in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81683 --- Comment #1 from Google-Autofuzz --- Created attachment 41908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41908=edit Demangler PoC
[Bug demangler/81683] New: Memory leak in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81683 Bug ID: 81683 Summary: Memory leak 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 41907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41907=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 (from another terminal, outside the container): docker cp /path/to/attached/reproducer :/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: ==42==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8 byte(s) in 1 object(s) allocated from: #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) Indirect leak of 1 byte(s) in 1 object(s) allocated from: #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 0x5100db in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31 #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) SUMMARY: AddressSanitizer: 9 byte(s) leaked in 2 allocation(s). 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
[Bug demangler/81682] New: Timeout in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81682 Bug ID: 81682 Summary: Timeout 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 41905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41905=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 (from another terminal, outside the container): docker cp /path/to/attached/reproducer :/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: None, the program exits after a few minutes 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
[Bug demangler/81682] Timeout in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81682 --- Comment #1 from Google-Autofuzz --- Created attachment 41906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41906=edit Demangler PoC
[Bug demangler/81681] Memory leak in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81681 --- Comment #1 from Google-Autofuzz --- Created attachment 41904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41904=edit Demangler PoC
[Bug demangler/81681] New: Memory leak in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81681 Bug ID: 81681 Summary: Memory leak 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 41903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41903=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 (from another terminal, outside the container): docker cp /path/to/attached/reproducer :/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: ==3170==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8 byte(s) in 1 object(s) allocated from: #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) Indirect leak of 1 byte(s) in 1 object(s) allocated from: #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 0x5100db in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31 #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) SUMMARY: AddressSanitizer: 9 byte(s) leaked in 2 allocation(s). 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
[Bug demangler/81680] Memory leak in demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81680 --- Comment #1 from Google-Autofuzz --- Created attachment 41902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41902=edit Demangle PoC
[Bug demangler/81680] New: Memory leak in demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81680 Bug ID: 81680 Summary: Memory leak in demangle 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 41901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41901=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 (from another terminal, outside the container): docker cp /path/to/attached/reproducer :/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: ==38==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x4d5c48 in malloc (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4d5c48) #1 0x536e39 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12 #2 0x51783e in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27 #3 0x515fcd in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18 #4 0x5138e0 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14 #5 0x51265c in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x51013d in LLVMFuzzerTestOneInput /fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20 #7 0x53f66c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f66c) Indirect leak of 3 byte(s) in 3 object(s) allocated from: #0 0x4d5c48 in malloc (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4d5c48) #1 0x536e39 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12 #2 0x517d9b in demangle_template /fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31 #3 0x515fcd in demangle_signature /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18 #4 0x5138e0 in internal_cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14 #5 0x51265c in cplus_demangle /fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9 #6 0x51013d in LLVMFuzzerTestOneInput /fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20 #7 0x53f66c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f66c) SUMMARY: AddressSanitizer: 27 byte(s) leaked in 4 allocation(s). 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
