Issue 56134 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section
Status: New Owner: CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izz...@google.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-elfutils Reported-2023-02-19 Type: Bug-Security New issue 56134 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134 Detailed Report: https://oss-fuzz.com/testcase?key=6724057145147392 Project: elfutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz-libdwfl Job Type: libfuzzer_msan_elfutils Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: check_section dwarf_begin_elf load_dw Sanitizer: memory (MSAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_elfutils&range=202302161800:202302181800 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6724057145147392 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
MemorySanitizer: Use-of-uninitialized-value in check_section
Hi, OSS-Fuzz found https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134 introduced in fda09f5f188fb173b2123815be71ca4647a8adfb but for some reason it wasn't delivered to the mailing list. I opened https://github.com/google/oss-fuzz/issues/9755 to figure out what went wrong there but until then below is the full backtrace: ``` ==2272==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5fb3c7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:265:7 #1 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 #2 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 #3 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 #4 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 #5 0x53c5b9 in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 #6 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 #7 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 #8 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #9 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 #10 0x458232 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #11 0x7fe0978dd0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #12 0x41f61d in _start Uninitialized value was created by a heap allocation #0 0x4e2310 in __interceptor_malloc /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:895:3 #1 0x6b9935 in convert_data /src/elfutils/libelf/elf_getdata.c:166:24 #2 0x6b9935 in __libelf_set_data_list_rdlock /src/elfutils/libelf/elf_getdata.c:455:7 #3 0x6ba571 in __elf_getdata_rdlock /src/elfutils/libelf/elf_getdata.c:562:5 #4 0x6ba6cd in elf_getdata /src/elfutils/libelf/elf_getdata.c:580:12 #5 0x5faec7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:246:20 #6 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 #7 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 #8 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 #9 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 #10 0x53c5b9 in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 #11 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 #12 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 #13 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #14 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 #15 0x458232 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #16 0x7fe0978dd0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_elfutils_3ee01cb67db1a71e7adeb7f3f14722ea62f13cd5/revisions/fuzz-libdwfl+0x5fb3c7) ``` It can be reproduced with `readelf` and `valgrind` ``` wget -O OSS-FUZZ-56134 'https://oss-fuzz.com/download?testcase_id=6724057145147392' LD_LIBRARY_PATH="$(pwd)/libdw:$(pwd)/libelf" DEBUGINFOD_URLS= valgrind --track-origins=yes ./src/readelf -w OSS-FUZZ-56134 ==1373524== Memcheck, a memory error detector ==1373524== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1373524== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1373524== Command: ./src/readelf -w OSS-FUZZ-56134 ==1373524== ==1373524== Conditional jump or move depends on uninitialised value(s) ==1373524== at 0x4887EAB: check_section (dwarf_begin_elf.c:265) ==1373524== by 0x48885EF: global_read (dwarf_begin_elf.c:444) ==1373524== by 0x48885EF: dwarf_begin_elf (dwarf_begin_elf.c:595) ==1373524== by 0x48A9F0C: load_dw (dwfl_module_getdwarf.c:1341) ==1373524== by 0x48AA0D0: find_dw (dwfl_module_getdwarf.c:1391) ==1373524== by 0x48AA0D0: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1446) ==1373524== by 0x411109: print_debug (readelf.c:11467) ==1373524== by 0x413A31: process_elf_file (readelf.c:1062) ==1373524== by 0x4148BC: process_dwflmod (readelf.c:818) ==1373524== by 0x48A7F20: dwfl_getmodules (dwfl_getmodules.c:86) ==1373524== by 0x40954A: process_file (readelf.c:926) ==1373524== by 0x404D0E: main (readelf.c:395) ==1373524== Uninitialised value was created by a heap allocation ==1373524== at 0x484586F: malloc (vg_replace_malloc.c:381) ==1373524== by 0x48FEA25: convert_data (elf_getdata.c:166) ==1373524== by 0x48FEA25: __libelf_set_data_list_rdlock (elf_getdata.c:455) ==1373524== by 0x48FE
Re: MemorySanitizer: Use-of-uninitialized-value in check_section
Hi Evgeny, On Sun, 2023-02-19 at 21:34 +0300, Evgeny Vereshchagin via Elfutils- devel wrote: > OSS-Fuzz found https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134 > introduced in fda09f5f188fb173b2123815be71ca4647a8adfb but for some > reason it wasn't delivered to the mailing list. I opened > https://github.com/google/oss-fuzz/issues/9755 to figure out what went > wrong there The email was slightly delayed because of a spam/virus scan issues: https://inbox.sourceware.org/overseers/abee4643c0e17900e094bf87460b99e628016fc5.ca...@klomp.org/T/#u But it reached the list eventually. Although it isn't in the inbox because it contains HTML, it is in the mailman archive now (stripped of the HTML): https://sourceware.org/pipermail/elfutils-devel/2023q1/005946.html The backtraces and valgrind reports are very helpful. It isn't really introduced by commit fda09f5f188fb173b2123815be71ca4647a8adfb "libdw: check that DWARF strings are null-terminated" but that commit exposes an issue in elf_getdata.c convert_data that probably existed for some time because it starts checking data from the end of the section (where there is garbage). It is probably in the "conversion function" not converting extra garbage data at the end. The issue is trying to get a big endian ELF file containing a .debug_line_str of type GNU_HASH (which is nonsensical in the first place). There are a couple of ways to "fix" this. I'll post some patch(es) soon. Thanks, Mark > but until then below is the full backtrace: > ``` > ==2272==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x5fb3c7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:265:7 > #1 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 > #2 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 > #3 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 > #4 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 > #5 0x53c5b9 in dwfl_module_getdwarf > /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 > #6 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 > #7 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, > unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 > #8 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, > unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 > #9 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned > char const*, unsigned long)) > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 > #10 0x458232 in main > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 > #11 0x7fe0978dd0b2 in __libc_start_main > /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 > #12 0x41f61d in _start > Uninitialized value was created by a heap allocation > #0 0x4e2310 in __interceptor_malloc > /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:895:3 > #1 0x6b9935 in convert_data /src/elfutils/libelf/elf_getdata.c:166:24 > #2 0x6b9935 in __libelf_set_data_list_rdlock > /src/elfutils/libelf/elf_getdata.c:455:7 > #3 0x6ba571 in __elf_getdata_rdlock /src/elfutils/libelf/elf_getdata.c:562:5 > #4 0x6ba6cd in elf_getdata /src/elfutils/libelf/elf_getdata.c:580:12 > #5 0x5faec7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:246:20 > #6 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 > #7 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 > #8 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 > #9 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 > #10 0x53c5b9 in dwfl_module_getdwarf > /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 > #11 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 > #12 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, > unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 > #13 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, > unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 > #14 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned > char const*, unsigned long)) > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 > #15 0x458232 in main > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 > #16 0x7fe0978dd0b2 in __libc_start_main > /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 > SUMMARY: MemorySanitizer: use-of-uninitialized-value > (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_elfutils_3ee01cb67db1a71e7adeb7f3f14722ea62f13cd5/revisions/fuzz-libdwfl+0x5fb3c7) > ``` > > It can be reproduced with `readelf` and `valgrind` > ``` > wget -O OSS-FUZZ-56134 > 'https://oss-fuzz.com/download?testcase_id=6724057145147392' > > LD_LIBRARY_PATH="$(pwd)/libdw:$(pwd)/libelf" DEBUGINFOD_URLS= valgrind > --track-origins=yes ./src/readelf -w OSS-FUZZ-56134 > ==1373524== Memcheck, a memory error detector > ==1
Issue 56134 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section
Comment #2 on issue 56134 by evv...@gmail.com: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134#c2 It can be confirmed with Valgrind: ``` wget -O OSS-FUZZ-56134 'https://oss-fuzz.com/download?testcase_id=6724057145147392' LD_LIBRARY_PATH="$(pwd)/libdw:$(pwd)/libelf" DEBUGINFOD_URLS= valgrind --track-origins=yes ./src/readelf -w OSS-FUZZ-56134 ==1373524== Memcheck, a memory error detector ==1373524== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1373524== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1373524== Command: ./src/readelf -w OSS-FUZZ-56134 ==1373524== ==1373524== Conditional jump or move depends on uninitialised value(s) ==1373524==at 0x4887EAB: check_section (dwarf_begin_elf.c:265) ==1373524==by 0x48885EF: global_read (dwarf_begin_elf.c:444) ==1373524==by 0x48885EF: dwarf_begin_elf (dwarf_begin_elf.c:595) ==1373524==by 0x48A9F0C: load_dw (dwfl_module_getdwarf.c:1341) ==1373524==by 0x48AA0D0: find_dw (dwfl_module_getdwarf.c:1391) ==1373524==by 0x48AA0D0: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1446) ==1373524==by 0x411109: print_debug (readelf.c:11467) ==1373524==by 0x413A31: process_elf_file (readelf.c:1062) ==1373524==by 0x4148BC: process_dwflmod (readelf.c:818) ==1373524==by 0x48A7F20: dwfl_getmodules (dwfl_getmodules.c:86) ==1373524==by 0x40954A: process_file (readelf.c:926) ==1373524==by 0x404D0E: main (readelf.c:395) ==1373524== Uninitialised value was created by a heap allocation ==1373524==at 0x484586F: malloc (vg_replace_malloc.c:381) ==1373524==by 0x48FEA25: convert_data (elf_getdata.c:166) ==1373524==by 0x48FEA25: __libelf_set_data_list_rdlock (elf_getdata.c:455) ==1373524==by 0x48FEC17: __elf_getdata_rdlock (elf_getdata.c:562) ==1373524==by 0x4887E6F: check_section (dwarf_begin_elf.c:246) ==1373524==by 0x48885EF: global_read (dwarf_begin_elf.c:444) ==1373524==by 0x48885EF: dwarf_begin_elf (dwarf_begin_elf.c:595) ==1373524==by 0x48A9F0C: load_dw (dwfl_module_getdwarf.c:1341) ==1373524==by 0x48AA0D0: find_dw (dwfl_module_getdwarf.c:1391) ==1373524==by 0x48AA0D0: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1446) ==1373524==by 0x411109: print_debug (readelf.c:11467) ==1373524==by 0x413A31: process_elf_file (readelf.c:1062) ==1373524==by 0x4148BC: process_dwflmod (readelf.c:818) ==1373524==by 0x48A7F20: dwfl_getmodules (dwfl_getmodules.c:86) ==1373524==by 0x40954A: process_file (readelf.c:926) ==1373524== ./src/readelf: cannot get debug context descriptor: No DWARF information found ``` -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56134 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section
Comment #1 on issue 56134 by evv...@gmail.com: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134#c1 Below is the full backtrace ``` ==2272==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5fb3c7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:265:7 #1 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 #2 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 #3 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 #4 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 #5 0x53c5b9 in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 #6 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 #7 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 #8 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #9 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 #10 0x458232 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #11 0x7fe0978dd0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 #12 0x41f61d in _start Uninitialized value was created by a heap allocation #0 0x4e2310 in __interceptor_malloc /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:895:3 #1 0x6b9935 in convert_data /src/elfutils/libelf/elf_getdata.c:166:24 #2 0x6b9935 in __libelf_set_data_list_rdlock /src/elfutils/libelf/elf_getdata.c:455:7 #3 0x6ba571 in __elf_getdata_rdlock /src/elfutils/libelf/elf_getdata.c:562:5 #4 0x6ba6cd in elf_getdata /src/elfutils/libelf/elf_getdata.c:580:12 #5 0x5faec7 in check_section /src/elfutils/libdw/dwarf_begin_elf.c:246:20 #6 0x5f8d3e in global_read /src/elfutils/libdw/dwarf_begin_elf.c:444:14 #7 0x5f8d3e in dwarf_begin_elf /src/elfutils/libdw/dwarf_begin_elf.c:595:9 #8 0x53f28c in load_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1341:13 #9 0x53c5b9 in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1391:16 #10 0x53c5b9 in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3 #11 0x534b72 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3 #12 0x43dcf3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15 #13 0x429452 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6 #14 0x42ecfc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9 #15 0x458232 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #16 0x7fe0978dd0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_elfutils_3ee01cb67db1a71e7adeb7f3f14722ea62f13cd5/revisions/fuzz-libdwfl+0x5fb3c7) ``` Looks like it was introduced in https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=fda09f5f188fb173b2123815be71ca4647a8adfb -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Fix some .debug checking and gnu hash xlate logic
Hi, The last fuzzer found some use (checking) of undefine/uninitialized data. Either of these two patches will fix that: [PATCH 1/2] libelf: memmove any extra bytes left by elf_cvt_gnuhash [PATCH 2/2] libdw: Use elf_rawdata when checking .debug section Note that the bad data wouldn't actually be used, just checked for validity. But these patches make sure the result is deterministic. Cheers, Mark
[PATCH 1/2] libelf: memmove any extra bytes left by elf_cvt_gnuhash conversion
Otherwise some undefined bytes might be left in the buffer. Now they
might still be not useful, but at least they are as defined in the
file.
Signed-off-by: Mark Wielaard
---
ChangeLog | 4
libelf/gnuhash_xlate.h | 12 ++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d99d837d..55787f64 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2023-02-20 Mark Wielaard
+
+ * gnuhash_xlate.h (elf_cvt_gnuhash): memmove any left over bytes.
+
2023-02-15 Mark Wielaard
* configure.ac: Error out when demangler is enabled, but
diff --git a/libelf/gnuhash_xlate.h b/libelf/gnuhash_xlate.h
index 6faf1136..3a00ae0a 100644
--- a/libelf/gnuhash_xlate.h
+++ b/libelf/gnuhash_xlate.h
@@ -1,5 +1,6 @@
/* Conversion functions for versioning information.
Copyright (C) 2006, 2007 Red Hat, Inc.
+ Copyright (C) 2023, Mark J. Wielaard
This file is part of elfutils.
Written by Ulrich Drepper , 2006.
@@ -36,6 +37,7 @@
static void
elf_cvt_gnuhash (void *dest, const void *src, size_t len, int encode)
{
+ size_t size = len;
/* The GNU hash table format on 64 bit machines mixes 32 bit and 64 bit
words. We must detangle them here. */
Elf32_Word *dest32 = dest;
@@ -45,7 +47,7 @@ elf_cvt_gnuhash (void *dest, const void *src, size_t len, int
encode)
for (unsigned int cnt = 0; cnt < 4; ++cnt)
{
if (len < 4)
- return;
+ goto done;
dest32[cnt] = bswap_32 (src32[cnt]);
len -= 4;
}
@@ -58,7 +60,7 @@ elf_cvt_gnuhash (void *dest, const void *src, size_t len, int
encode)
for (unsigned int cnt = 0; cnt < bitmask_words; ++cnt)
{
if (len < 8)
- return;
+ goto done;
dest64[cnt] = bswap_64 (src64[cnt]);
len -= 8;
}
@@ -71,4 +73,10 @@ elf_cvt_gnuhash (void *dest, const void *src, size_t len,
int encode)
*dest32++ = bswap_32 (*src32++);
len -= 4;
}
+
+ done:
+ /* If there are any bytes left, we weren't able to convert the
+ partial structures, just copy them over. */
+ if (len > 0)
+memmove (dest + size - len, src + size - len, len);
}
--
2.39.2
[PATCH 2/2] libdw: Use elf_rawdata when checking .debug section
.debug sections are raw bytes and don't need conversion even when host and file have different endian order. Signed-off-by: Mark Wielaard --- libdw/ChangeLog | 4 libdw/dwarf_begin_elf.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/libdw/ChangeLog b/libdw/ChangeLog index e0cd8f21..5e60f786 100644 --- a/libdw/ChangeLog +++ b/libdw/ChangeLog @@ -1,3 +1,7 @@ +2023-02-20 Mark Wielaard + + * dwarf_begin_elf.c (check_section): Use elf_rawdata. + 2023-02-14 Mark Wielaard * dwarf_getlocation.c (__libdw_intern_expression): Correct check diff --git a/libdw/dwarf_begin_elf.c b/libdw/dwarf_begin_elf.c index 1d4bb333..92d76d24 100644 --- a/libdw/dwarf_begin_elf.c +++ b/libdw/dwarf_begin_elf.c @@ -1,5 +1,6 @@ /* Create descriptor from ELF descriptor for processing file. Copyright (C) 2002-2011, 2014, 2015, 2017, 2018 Red Hat, Inc. + Copyright (C) 2023, Mark J. Wielaard This file is part of elfutils. This file is free software; you can redistribute it and/or modify @@ -242,8 +243,8 @@ check_section (Dwarf *result, size_t shstrndx, Elf_Scn *scn, bool inscngrp) } } - /* Get the section data. */ - Elf_Data *data = elf_getdata (scn, NULL); + /* Get the section data. Should be raw bytes, no conversion needed. */ + Elf_Data *data = elf_rawdata (scn, NULL); if (data == NULL) goto err; -- 2.39.2
Re: [PATCH 2/2] libdw: Use elf_rawdata when checking .debug section
Hello, Mark On Mon, Feb 20, 2023 at 3:55 PM Mark Wielaard wrote: > > .debug sections are raw bytes and don't need conversion even when host > and file have different endian order. Thank you! I like this patch more for its simplicity, looks good to me.
Issue 56179 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section
Status: New Owner: CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izz...@google.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-elfutils Reported-2023-02-20 Type: Bug-Security New issue 56179 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56179 Detailed Report: https://oss-fuzz.com/testcase?key=6538272475316224 Project: elfutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz-libdwfl Job Type: libfuzzer_msan_elfutils Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: check_section dwarf_begin_elf load_dw Sanitizer: memory (MSAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_elfutils&range=202302161800:202302181800 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6538272475316224 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56179 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section
Comment #1 on issue 56179 by evv...@gmail.com: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in check_section https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56179#c1 It's a duplicate of https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56134 as far as I can tell. I'm not sure why it was reported once again. I opened https://github.com/google/oss-fuzz/issues/9769. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Re: [PATCH 2/2] libdw: Use elf_rawdata when checking .debug section
Hi, On Mon, 20 Feb 2023 at 19:03, Aleksei Vetrov wrote: > On Mon, Feb 20, 2023 at 3:55 PM Mark Wielaard wrote: > > > > .debug sections are raw bytes and don't need conversion even when host > > and file have different endian order. > > Thank you! I like this patch more for its simplicity, looks good to me. Agreed. I haven't actually tested the patch though but since it's covered by the fuzz target it should be tested once it's merged anyway. On a somewhat related looking at some recent patches and especially https://sourceware.org/git/?p=elfutils.git;a=commit;h=64ee2cb792e7b6ba6ad2a5759bff7ce8714e4668 it seems apart from OSS-Fuzz elfutils is fuzzed elsewhere. Aleksei I wonder if it would be possible to add those fuzz targets to OSS-Fuzz? There are blind spots there and I think it would be really great to start covering at least some of them. Thanks, Evgeny Vereshchagin
