Re: Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
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, > izz...@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: 0x00a0 > Crash State: > chunk_compare > __tsearch > elf_getdata_rawchunk > > Sanitizer: address (ASAN) > > Crash Revision: > https://oss-fuzz.com/revisions?job=libfuzzer_asan_i386_elfutils&revision=20230824 > > 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
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 >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7 #16 0x808d1de in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector >&) /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
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 std::__Fuzzer::allocator >&) > /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7 > #16 0x808d1de in > fuzzer::Fuzzer::Loop(std::__Fuzzer::vector std::__Fuzzer::allocator >&) > /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
[PATCH] PR28204, debuginfod IMA
Hi -
Here's a squashed/rebased version of the big IMA patch. I also
tweaked a few documentation oriented bits, and removed the
"ima:default" tag.
commit 4e45a08aee42958298a3fad6043cbf96243d13a5 (HEAD ->
users/fche/try-bz28204, origin/users/fche/try-bz28204)
Author: Ryan Goldberg
Date: Mon Aug 14 13:51:00 2023 -0400
debuginfod: PR28204 - RPM IMA per-file signature verification
Recent versions of Fedora/RHEL include per-file cryptographic
signatures in RPMs, not just an overall RPM signature. This work
extends debuginfod client & server to extract, transfer, and verify
those signatures. These allow clients to assure users that the
downloaded files have not been corrupted since their original
packaging. Downloads that fail the test are rejected.
Clients may select a desired level of enforcement for sets of URLs in
the DEBUGINFOD_URLS by inserting special markers ahead of them:
ima:ignore pay no attention to absence or presence of signatures
ima:permissive require signatures to be correct, but accept absent
signatures
ima:enforcingrequire every file to be correctly signed
The default is ima:permissive mode, which allows signatures to
function like a checksum to detect accidental corruption, but accepts
operation in a mix of signed and unsigned packages & servers.
NB: debuginfod section queries are excluded from signature
verification at this time, and function as though ima:ignore were in
effect.
IMA signatures are verified against a set of signing certificates.
These are normally published by distributions. A selection of such
certificates is included with the debuginfod client, but some system
directories are also searched. See $DEBUGINFOD_IMA_CERT_PATH. These
certificates are assumed trusted.
Signed-off-by: Ryan Goldberg
Signed-off-by: Frank Ch. Eigler
diff --git a/ChangeLog b/ChangeLog
index 6aed95b6974e..b3b1a8ebc93a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2023-08-14 Ryan Goldberg
+
+ * configure.ac (ENABLE_IMA_VERIFICATION): Look for librpm, libimaevm
and libcrypto
+ * (DEBUGINFOD_IMA_CERT_PATH): Default path for ima certificate
containing
+ dirs. See also profile.*.in.
+
2023-03-27 Di Chen
* NEWS: Support readelf -Ds for using dynamic segment to
diff --git a/config/ChangeLog b/config/ChangeLog
index ce1f74f621aa..30fc3deea09e 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,10 @@
+2023-08-14 Ryan Goldberg
+
+ * profile.csh.in: Set DEBUGINFOD_IMA_CERT_PATH directly.
+ * profile.sh.in: Set DEBUGINFOD_IMA_CERT_PATH directly.
+ * elfutils.spec.in: Add BuildRequires rpm-devel,
+ ima-evm-utils-devel, openssl-devel, rpm-sign.
+
2023-02-21 Mark Wielaard
* eu.am (USE_AFTER_FREE3_WARNING): Define.
diff --git a/config/elfutils.spec.in b/config/elfutils.spec.in
index 9277c08f7c82..2e962bb40d07 100644
--- a/config/elfutils.spec.in
+++ b/config/elfutils.spec.in
@@ -43,6 +43,12 @@ BuildRequires: curl
# For run-debuginfod-response-headers.sh test case
BuildRequires: socat
+# For debuginfod rpm IMA verification
+BuildRequires: rpm-devel
+BuildRequires: ima-evm-utils-devel
+BuildRequires: openssl-devel
+BuildRequires: rpm-sign
+
%define _gnu %{nil}
%define _programprefix eu-
diff --git a/config/profile.csh.in b/config/profile.csh.in
index d962d969c05b..2a2ecacb3c80 100644
--- a/config/profile.csh.in
+++ b/config/profile.csh.in
@@ -4,13 +4,17 @@
# See also [man debuginfod-client-config] for other environment variables
# such as $DEBUGINFOD_MAXSIZE, $DEBUGINFOD_MAXTIME, $DEBUGINFOD_PROGRESS.
+set prefix="@prefix@"
if (! $?DEBUGINFOD_URLS) then
-set prefix="@prefix@"
set DEBUGINFOD_URLS=`sh -c 'cat /dev/null "$0"/*.urls 2>/dev/null; :'
"@sysconfdir@/debuginfod" | tr '\n' ' '`
if ( "$DEBUGINFOD_URLS" != "" ) then
setenv DEBUGINFOD_URLS "$DEBUGINFOD_URLS"
+if (! $?DEBUGINFOD_IMA_CERT_PATH) then
+set
DEBUGINFOD_IMA_CERT_PATH="@sysconfdir@/debuginfod/ima-certs/:@DEBUGINFOD_IMA_CERT_PATH@"
+setenv DEBUGINFOD_IMA_CERT_PATH "$DEBUGINFOD_IMA_CERT_PATH"
+endif
else
unset DEBUGINFOD_URLS
endif
-unset prefix
endif
+unset prefix
diff --git a/config/profile.sh.in b/config/profile.sh.in
index 3f4397dcb44d..adc06a7ed939 100644
--- a/config/profile.sh.in
+++ b/config/profile.sh.in
@@ -4,9 +4,14 @@
# See also [man debuginfod-client-config] for other environment variables
# such as $DEBUGINFOD_MAXSIZE, $DEBUGINFOD_MAXTIME, $DEBUGINFOD_PROGRESS.
+prefix="@prefix@"
if [ -z "$DEBUGINFOD_URLS" ]; then
-prefix="@prefix@"
DEBUGINFOD_URLS=$(cat /dev/null "@sysconfdir@/debuginfod"/*.urls
2>/dev/null | tr '\n' ' ')
[ -n "$DEBUGINFOD_URLS" ] && export DEBUGINFOD_URLS || unset
DEBUGINFOD_URLS
-unset prefix
+
+if [ -z "$DEBUGINFOD_IMA_CERT_PATH" ]; then
+
Issue 62071 in oss-fuzz: elfutils:fuzz-libdwfl: Null-dereference READ in chunk_compare
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
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
From 189a689a73db567f2c2ca30d805665672cae01b4 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
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
---
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
