Re: Issue 46192 in oss-fuzz: elfutils:fuzz-libdwfl: Out-of-memory in fuzz-libdwfl

[Mark Wielaard <mark@klomp.org>]

Hi,

On Wed, Mar 30, 2022 at 03:24:17PM -0700, ClusterFuzz-External via monorail via Elfutils-devel wrote:
> New issue 46192 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Out-of-memory in fuzz-libdwfl
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46192
> 
> Detailed Report: https://oss-fuzz.com/testcase?key=5364854623436800
> 
> Project: elfutils
> Fuzzing Engine: libFuzzer
> Fuzz Target: fuzz-libdwfl
> Job Type: libfuzzer_asan_elfutils
> Platform Id: linux
> 
> Crash Type: Out-of-memory (exceeds 2560 MB)
> Crash Address: 
> Crash State:
>   fuzz-libdwfl
>   
> Sanitizer: address (ASAN)
> 
> Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_elfutils&range=202203161800:202203170000
> 
> Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5364854623436800

The issue with this testcase is that it has hundreds of (bad) PT_NOTE
segements. We are trying to find the build-id. For each (bogus)
PT_NOTE segement we call elf_getdata_rawchunk. There is no way to get
rid of a raw data chunk, except closing the Elf. So they just
accumulate till we run out of memory.

I don't know of a good interface to dispose of raw data chunks. But we
could mitigate this a bit by rejecting zero sized rawchunks and
searching the rawchunks to see if we already have created a chunk for
the requested offset, size and type. We currently don't keep track of
the original offset, so that would need to be tracked then.

Cheers,

Mark