Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[ClusterFuzz-External via monorail]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

Status: New
Owner: ----
CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izzeem@google.com 
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Unreproducible Engine-libfuzzer OS-Linux Proj-elfutils Reported-2023-09-06
Type: Bug

New issue 62071 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071

Detailed Report: https://oss-fuzz.com/testcase?key=5999675550072832

Project: elfutils
Fuzzing Engine: libFuzzer
Fuzz Target: fuzz-libdwfl
Job Type: libfuzzer_asan_i386_elfutils
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000a0
Crash State:
  chunk_compare
  __tsearch
  elf_getdata_rawchunk
  
Sanitizer: address (ASAN)

Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_i386_elfutils&revision=202308240000

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5999675550072832

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.

************************* UNREPRODUCIBLE *************************
Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days, we've been seeing this crash frequently.

It may be possible to reproduce by trying the following options:
- Run testcase multiple times for a longer duration.
- Run fuzzing without testcase argument to hit the same crash signature.

If it still does not reproduce, try a speculative fix based on the crash stacktrace and verify if it works by looking at the crash statistics in the report. We will auto-close the bug if the crash is not seen for 14 days.
******************************************************************
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.

Re: Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[Mark Wielaard]

Hi Evgeny,

Do you happen to know what clusterfuzz is trying to tell us? The
detailed report and reproducer testcase are not accessible (they
seems to require a google or github account to login).

It looks like somehow a NULL key got into the search tree. But I cannot
figure out how that would happen.

Thanks,

Mark

On Tue, 2023-09-05 at 22:01 -0700, ClusterFuzz-External via monorail
via Elfutils-devel wrote:
> Status: New
> Owner: ----
> CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izzeem@google.com 
> Labels: ClusterFuzz Stability-Memory-AddressSanitizer Unreproducible Engine-libfuzzer OS-Linux Proj-elfutils Reported-2023-09-06
> Type: Bug
> 
> New issue 62071 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071
> 
> Detailed Report: https://oss-fuzz.com/testcase?key=5999675550072832
> 
> Project: elfutils
> Fuzzing Engine: libFuzzer
> Fuzz Target: fuzz-libdwfl
> Job Type: libfuzzer_asan_i386_elfutils
> Platform Id: linux
> 
> Crash Type: Null-dereference READ
> Crash Address: 0x000000a0
> Crash State:
>   chunk_compare
>   __tsearch
>   elf_getdata_rawchunk
>   
> Sanitizer: address (ASAN)
> 
> Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_i386_elfutils&revision=202308240000
> 
> Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5999675550072832
> 
> Issue filed automatically.
> 
> See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
> 
> ************************* UNREPRODUCIBLE *************************
> Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days, we've been seeing this crash frequently.
> 
> It may be possible to reproduce by trying the following options:
> - Run testcase multiple times for a longer duration.
> - Run fuzzing without testcase argument to hit the same crash signature.
> 
> If it still does not reproduce, try a speculative fix based on the crash stacktrace and verify if it works by looking at the crash statistics in the report. We will auto-close the bug if the crash is not seen for 14 days.
> ******************************************************************
> 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.
> 

Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[evv… via monorail]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]


Comment #1 on issue 62071 by evv...@gmail.com: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c1

```
SCARINESS: 10 (null-deref)
    #0 0x82d35d1 in chunk_compare /src/elfutils/libelf/elf_getdata_rawchunk.c:49:25
    #1 0xf7caab3a in __tsearch
    #2 0x8156826 in __interceptor_tsearch /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:6057:15
    #3 0x82d2a8a in elf_getdata_rawchunk /src/elfutils/libelf/elf_getdata_rawchunk.c:98:28
    #4 0x81f4139 in find_elf_build_id /src/elfutils/libdwelf/dwelf_elf_gnu_build_id.c:88:28
    #5 0x81f3a28 in __libdwfl_find_elf_build_id /src/elfutils/libdwelf/dwelf_elf_gnu_build_id.c:142:10
    #6 0x82795e8 in __libdwfl_find_build_id /src/elfutils/libdwfl/dwfl_module_build_id.c:70:16
    #7 0x82795e8 in dwfl_module_build_id /src/elfutils/libdwfl/dwfl_module_build_id.c:91:20
    #8 0x81d7ec7 in dwfl_standard_find_debuginfo /src/elfutils/libdwfl/find-debuginfo.c:365:19
    #9 0x81d3340 in find_debuginfo /src/elfutils/libdwfl/dwfl_module_getdwarf.c:538:19
    #10 0x81cff0f in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1412:16
    #11 0x81cff0f in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3
    #12 0x81cad03 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3
    #13 0x808ba2e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #14 0x808b168 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned int, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #15 0x808cfdd in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
    #16 0x808d1de in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
    #17 0x807c3fc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #18 0x80a6177 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #19 0xf7bc5ed4 in __libc_start_main
    #20 0x806dad5 in _start
```
The fuzz target can be found at https://github.com/google/oss-fuzz/blob/master/projects/elfutils/fuzz-libdwfl.c

OSS-Fuzz says the fuzz target crashed on i386 sporadically and it isn't reliably reproducible anymore so it could be a glitch of some sort.

-- 
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: Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[Mark Wielaard]

Hi Evgeny,

On Thu, 2023-09-07 at 05:31 -0700, evv… via monorail via Elfutils-devel
wrote:
> Comment #1 on issue 62071 by evv...@gmail.com: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c1
> 
> ```
> SCARINESS: 10 (null-deref)
>     #0 0x82d35d1 in chunk_compare /src/elfutils/libelf/elf_getdata_rawchunk.c:49:25
>     #1 0xf7caab3a in __tsearch
>     #2 0x8156826 in __interceptor_tsearch /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:6057:15
>     #3 0x82d2a8a in elf_getdata_rawchunk /src/elfutils/libelf/elf_getdata_rawchunk.c:98:28
>     #4 0x81f4139 in find_elf_build_id /src/elfutils/libdwelf/dwelf_elf_gnu_build_id.c:88:28
>     #5 0x81f3a28 in __libdwfl_find_elf_build_id /src/elfutils/libdwelf/dwelf_elf_gnu_build_id.c:142:10
>     #6 0x82795e8 in __libdwfl_find_build_id /src/elfutils/libdwfl/dwfl_module_build_id.c:70:16
>     #7 0x82795e8 in dwfl_module_build_id /src/elfutils/libdwfl/dwfl_module_build_id.c:91:20
>     #8 0x81d7ec7 in dwfl_standard_find_debuginfo /src/elfutils/libdwfl/find-debuginfo.c:365:19
>     #9 0x81d3340 in find_debuginfo /src/elfutils/libdwfl/dwfl_module_getdwarf.c:538:19
>     #10 0x81cff0f in find_dw /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1412:16
>     #11 0x81cff0f in dwfl_module_getdwarf /src/elfutils/libdwfl/dwfl_module_getdwarf.c:1446:3
>     #12 0x81cad03 in LLVMFuzzerTestOneInput /src/fuzz-libdwfl.c:54:3
>     #13 0x808ba2e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
>     #14 0x808b168 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned int, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
>     #15 0x808cfdd in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
>     #16 0x808d1de in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
>     #17 0x807c3fc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
>     #18 0x80a6177 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
>     #19 0xf7bc5ed4 in __libc_start_main
>     #20 0x806dad5 in _start
> ```
> The fuzz target can be found at https://github.com/google/oss-fuzz/blob/master/projects/elfutils/fuzz-libdwfl.c

Thanks. But this doesn't really get me much further. Somehow a NULL key
got into the search tree and I am still unclear how that can happen.

If there is a reproducer/input file that would be really helpful.

Cheers,

Mark

Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[evv… via monorail]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]


Comment #2 on issue 62071 by evv...@gmail.com: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c2

For some reason the testcase isn't public. I'll report it to OSS-Fuzz.

I uploaded the test case to GitHub so now it should be
possible to download it from https://github.com/evverx/elfutils/files/12549426/clusterfuzz-testcase-fuzz-libdwfl-5999675550072832.gz

-- 
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: Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Thu, 2023-09-07 at 06:23 -0700, evv… via monorail via Elfutils-devel
wrote:
> Comment #2 on issue 62071 by evv...@gmail.com: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c2
> 
> For some reason the testcase isn't public. I'll report it to OSS-Fuzz.
> 
> I uploaded the test case to GitHub so now it should be
> possible to download it from https://github.com/evverx/elfutils/files/12549426/clusterfuzz-testcase-fuzz-libdwfl-5999675550072832.gz
> 

Thanks. Unfortunately I have still been unable to replicate the crash.
But by reading the code carefully I think I have identified how this
might happen. You must get a somewhat unfortunate out of memory or read
error at precisely the wrong point. The attached patch should fix it.

Cheers,

Mark

[-- Attachment #2: 0001-libelf-tdelete-dummy-key-if-anything-goes-wrong-sett.patch --]
[-- Type: text/x-patch, Size: 2030 bytes --]

From 189a689a73db567f2c2ca30d805665672cae01b4 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Thu, 7 Sep 2023 16:14:43 +0200
Subject: [PATCH] libelf: tdelete dummy key if anything goes wrong setting up
 rawchunk

elf_getdata_rawchunk uses a binary search tree cache. If a rawchunk is
not yet in the cache we setup a new entry. But if anything went wrong
setting up the new rawchunk we would leave a NULL key in the
cache. This could blow up the next search. Fix this by removing the
(dummy) key from the cache on any failure.

	* libelf/elf_getdata_rawchunk.c (elf_getdata_rawchunk): Don't
	assign NULL to *found. Call tdelete if anything goes wrong.

Signed-off-by: Mark Wielaard <mark@klomp.org>
---
 libelf/elf_getdata_rawchunk.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libelf/elf_getdata_rawchunk.c b/libelf/elf_getdata_rawchunk.c
index cfd40396..05ff329c 100644
--- a/libelf/elf_getdata_rawchunk.c
+++ b/libelf/elf_getdata_rawchunk.c
@@ -107,8 +107,10 @@ elf_getdata_rawchunk (Elf *elf, int64_t offset, size_t size, Elf_Type type)
       goto out;
     }
 
-  /* New entry.  */
-  *found = NULL;
+  /* New entry.  Note that *found will point to the newly inserted
+     (dummy) key.  We'll replace it with a real rawchunk when that is
+     setup.  Make sure to tdelete the dummy key if anything goes
+     wrong.  */
 
   size_t align = __libelf_type_align (elf->class, type);
   if (elf->map_address != NULL)
@@ -134,6 +136,7 @@ elf_getdata_rawchunk (Elf *elf, int64_t offset, size_t size, Elf_Type type)
       if (rawchunk == NULL)
 	{
 	nomem:
+	  tdelete (&key, &elf->state.elf.rawchunks, &chunk_compare);
 	  __libelf_seterrno (ELF_E_NOMEM);
 	  goto out;
 	}
@@ -144,6 +147,7 @@ elf_getdata_rawchunk (Elf *elf, int64_t offset, size_t size, Elf_Type type)
 		    != size))
 	{
 	  /* Something went wrong.  */
+	  tdelete (&key, &elf->state.elf.rawchunks, &chunk_compare);
 	  free (rawchunk);
 	  __libelf_seterrno (ELF_E_READ_ERROR);
 	  goto out;
-- 
2.41.0

Re: Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[Mark Wielaard]

Hi,

On Thu, Sep 07, 2023 at 04:25:00PM +0200, Mark Wielaard wrote:
> Subject: [PATCH] libelf: tdelete dummy key if anything goes wrong setting up
>  rawchunk
> 
> elf_getdata_rawchunk uses a binary search tree cache. If a rawchunk is
> not yet in the cache we setup a new entry. But if anything went wrong
> setting up the new rawchunk we would leave a NULL key in the
> cache. This could blow up the next search. Fix this by removing the
> (dummy) key from the cache on any failure.
> 
> 	* libelf/elf_getdata_rawchunk.c (elf_getdata_rawchunk): Don't
> 	assign NULL to *found. Call tdelete if anything goes wrong.

Pushed,

Mark

Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[ClusterFuzz-External via monorail]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Updates:
	Status: WontFix

Comment #3 on issue 62071 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c3

ClusterFuzz testcase 5999675550072832 is flaky and no longer crashes, so closing issue.

If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new

-- 
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 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare

[ClusterFuzz-External via monorail]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]


Comment #4 on issue 62071 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62071#c4

ClusterFuzz testcase 5999675550072832 is closed as invalid, so closing issue.

-- 
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.