From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3880D3858D35 for ; Sun, 30 Jul 2023 12:03:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3880D3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id AE9F0300027E; Sun, 30 Jul 2023 14:03:09 +0200 (CEST) Date: Sun, 30 Jul 2023 14:03:09 +0200 From: Mark Wielaard To: elfutils-devel@sourceware.org Cc: =?utf-8?B?ZXZ24oCm?= via monorail Subject: Re: Issue 60887 in oss-fuzz: elfutils:fuzz-libelf: Direct-leak in __libelf_decompress_zlib Message-ID: <20230730120309.GG28605@gnu.wildebeest.org> References: <0=71cc74a7ba1af446b7ed6b9a08b414d9=179906139b10d40134117f89b865bd88=oss-fuzz@monorail-prod.appspotmail.com> <0000000000008b795d0601a754da@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0000000000008b795d0601a754da@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3029.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Sat, Jul 29, 2023 at 03:00:49PM -0700, evv… via monorail via Elfutils-devel wrote: > > Comment #1 on issue 60887 by evv...@gmail.com: elfutils:fuzz-libelf: Direct-leak in __libelf_decompress_zlib > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60887#c1 > > The full backtrace is > ``` > ==178009==ERROR: LeakSanitizer: detected memory leaks > Direct leak of 1 byte(s) in 1 object(s) allocated from: > #0 0x52efd6 in __interceptor_malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 > #1 0x57a228 in __libelf_decompress_zlib /src/elfutils/libelf/elf_compress.c:370:19 > #2 0x57a987 in __libelf_decompress /src/elfutils/libelf/elf_compress.c:440:12 > #3 0x57a987 in __libelf_decompress_elf /src/elfutils/libelf/elf_compress.c:500:7 > #4 0x57629f in get_zdata /src/elfutils/libelf/elf_strptr.c:45:17 > #5 0x575c5e in elf_strptr /src/elfutils/libelf/elf_strptr.c:135:38 > #6 0x56c5b3 in fuzz_logic_one /src/fuzz-libelf.c:40:26 > #7 0x56cc7f in LLVMFuzzerTestOneInput /src/fuzz-libelf.c:88:3 > ``` > > I haven't figured out how to trigger that memory leak without the fuzz target > but as far as I can tell `fuzz_logic_one` was inspired by the elfgetzdata test in > the sense that it calls elf_nextscn/elf_strptr/elf_compress. > > The code triggering the memory leak is > https://github.com/google/oss-fuzz/blob/24328c88fd610decaf311020ffc7073aec1db252/projects/elfutils/fuzz-libelf.c#L27C6-L27C20 Thanks, I can replicate it with that and valgrind. The issue is when elf_strptr has (partially) uncompressed the section data (to read the uncompressed string), the program never requests the (uncompressed) section data, but does (re)compress it. Working on a fix. Cheers, Mark