Re: [PATCH] debuginfod: Clear and reset debuginfod_client winning_headers on reuse
Hi Frank, On Mon, 2021-12-06 at 13:41 -0500, Frank Ch. Eigler wrote: > gcc address sanitizer detected a leak of the debuginfod_client > > winning_headers when the handle was reused. Make sure to free and > > reset the winning_headers field before reuse. > > This is good. Thanks, pushed. Cheers, Mark
[Bug libelf/28666] New: memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 Bug ID: 28666 Summary: memmove() reads out-of-range in elf32_xlatetom Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: netfirewall at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13829 --> https://sourceware.org/bugzilla/attachment.cgi?id=13829&action=edit poc1 Hi, A memmove() reads out-of-range was triggered when we were fuzzing the elfutils. The same issue can be triggered in the release version 0.186 and the upstream version. We fuzzed with a modified oss-fuzz, so it can be reproduced with oss-fuzz steup. Here are the steps to reproduce (poc1 is attached): > 1. git clone https://github.com/google/oss-fuzz.git > 2. cd oss-fuzz > 3. python3 infra/helper.py build_fuzzers --engine libfuzzer --sanitizer > address elfutils > 4. python3 infra/helper.py reproduce elfutils fuzz-dwfl-core ./poc1 The same payload also crashes the release 0.186 (commit 983e86fd89e8bf02f2d27ba5dce5bf078af4ceda). To reproduce on 0.186, edit oss-fuzz/projects/elfutils/Dockerfile as below, and follow the same steps above. > FROM gcr.io/oss-fuzz-base/base-builder > RUN apt-get update && \ > apt-get install -y pkg-config make autoconf autopoint zlib1g-dev flex > bison gawk > RUN git clone git://sourceware.org/git/elfutils.git > WORKDIR elfutils > RUN git checkout 983e86fd89e8bf02f2d27ba5dce5bf078af4ceda > COPY build.sh *.c *.zip $SRC/ Here is the ASAN dump (upstream, commit 66f704ae705a489d35cd03aa9687e192a844d766): > ==13==ERROR: AddressSanitizer: unknown-crash on address 0x7fab2f62e000 at pc > 0x0052487f bp 0x7ffe9c2ec120 sp 0x7ffe9c2eb8e8[35/1970] > READ of size 1790976 at 0x7fab2f62e000 thread T0 > > SCARINESS: 16 (multi-byte-read-unknown-crash) > > #0 0x52487e in __asan_memmove > /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3 > > #1 0x63ca73 in memmove > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10 > > #2 0x63ca73 in elf32_xlatetom /src/elfutils/libelf/elf32_xlatetom.c:96:2 > > #3 0x5fc040 in dwfl_link_map_report > /src/elfutils/libdwfl/link_map.c:895:12 > > #4 0x56631a in dwfl_core_file_report > /src/elfutils/libdwfl/core-file.c:548:16 > > #5 0x55e4e0 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6 > > #6 0x456cb3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, > unsigned long) cxa_noexception.cpp > #7 0x4425b2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned > long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver > .cpp:324:6 > > #8 0x44807a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char > const*, unsigned long)) cxa_noexception.cpp > #9 0x470f62 in main > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 > > #10 0x7fab304800b2 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > > #11 0x41f83d in _start (/out/fuzz-dwfl-core+0x41f83d) > > > > DEDUP_TOKEN: __asan_memmove--memmove--elf32_xlatetom > > Address 0x7fab2f62e000 is a wild pointer inside of access range of size > 0x001b5400. > SUMMARY: AddressSanitizer: unknown-crash > /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3 > in __asan_memmo > ve > > Shadow bytes around the buggy address: > > 0x0ff5e5ebdbb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 Evgeny Vereshchagin changed: What|Removed |Added CC||evvers at ya dot ru --- Comment #1 from Evgeny Vereshchagin --- FWIW There are a lot of moving parts there so in https://github.com/google/oss-fuzz/pull/6944 I tried to make it easier to reproduce bugs found by the fuzz target without Docker used by the oss-fuzz toolchain. To that end I added a comment where I tried to explain how to build it manually with clang and the build dependencies of elfutils: https://github.com/google/oss-fuzz/blob/5f83a8b6811eaa6b1a0aa574e095ed0def8a0ce3/projects/elfutils/build.sh#L18-L36. Apart from that I'm pretty sure all the bugs that can be found by the fuzz target (in its current form at least) can be triggered with `./src/stack --core ...` built with ASan/UBsan or under Valgrind so this particular issue can be triggered by running something like ``` autoreconf -i -f ./configure --enable-maintainer-mode CFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' CXXFLAGS='-g -O1 -fno-omit-frame-pointer -fsanitize=address' ASAN_OPTIONS=detect_leaks=0 make -j$(nproc) V=1 $ LD_PRELOAD="/lib64/libasan.so.6 ./libelf/libelf.so ./libdw/libdw.so" ./src/stack --core ../poc1 AddressSanitizer:DEADLYSIGNAL = ==52660==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd5b4e5d000 (pc 0x7fd5b8a86368 bp 0x7fff4773cb50 sp 0x7fff4773cb18 T0) ==52660==The signal is caused by a READ memory access. #0 0x7fd5b8a86368 in __sanitizer::internal_memmove(void*, void const*, unsigned long) (/lib64/libasan.so.6+0xc5368) #1 0x7fd5b898aa42 in memmove /usr/include/bits/string_fortified.h:36 #2 0x7fd5b898aa42 in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:96 #3 0x7fd5b88c285b in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:895 #4 0x7fd5b88c7877 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:548 #5 0x4037b8 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #6 0x7fd5b84bef81 in __argp_parse (/lib64/libc.so.6+0x10cf81) #7 0x404b7d in main /home/vagrant/elfutils/src/stack.c:695 #8 0x7fd5b83d9b74 in __libc_start_main (/lib64/libc.so.6+0x27b74) #9 0x40256d in _start (/home/vagrant/elfutils/src/stack+0x40256d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.6+0xc5368) in __sanitizer::internal_memmove(void*, void const*, unsigned long) ==52660==ABORTING ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28666] memmove() reads out-of-range in elf32_xlatetom
https://sourceware.org/bugzilla/show_bug.cgi?id=28666 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |mark at klomp dot org CC||mark at klomp dot org Last reconfirmed||2021-12-07 --- Comment #2 from Mark Wielaard --- It does indeed replicate under valgrind using eu-stack with any build: $ valgrind eu-stack --core poc1 ==444== Memcheck, a memory error detector ==444== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==444== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==444== Command: eu-stack --core poc1 ==444== ==444== Invalid read of size 8 ==444==at 0x4C2E68C: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1034) ==444==by 0x4E3C2FB: UnknownInlinedFun (string3.h:57) ==444==by 0x4E3C2FB: elf32_xlatetom (elf32_xlatetom.c:100) ==444==by 0x5086081: dwfl_link_map_report (link_map.c:894) ==444==by 0x5087D7A: dwfl_core_file_report@@ELFUTILS_0.158 (core-file.c:532) ==444==by 0x402736: parse_opt (stack.c:590) ==444==by 0x58B7E83: group_parse (argp-parse.c:256) ==444==by 0x58B7E83: parser_finalize (argp-parse.c:603) ==444==by 0x58B7E83: argp_parse (argp-parse.c:921) ==444==by 0x401CE5: main (stack.c:690) ==444== Address 0x4025000 is not stack'd, malloc'd or (recently) free'd I see what is going on. In link_map we try to read in the phdrs, but we can only read a small amount (the ph_num field is crazy big). So we set the in.d_size to just the size we can read in. But then for the conversion we set out.d_size based on the crazy big ph_num. Then we try to convert not just the phdrs that we could read, but a much bigger amount. And crash... This is an odd failure, it only happens when trying to read a big endian core file on an little endian architecture (or the other way around), and that core file is also clearly corrupted. -- You are receiving this mail because: You are on the CC list for the bug.
