[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binutils
Subject:    Re: asan: mmo: NULL dereferenc in mmo_xore_32
From:       Alan Modra via Binutils <binutils () sourceware ! org>
Date:       2021-10-28 23:59:25
Message-ID: YXs2jaFtY4XR+3qX () squeak ! grove ! modra ! org
[Download RAW message or body]


On Thu, Oct 28, 2021 at 06:38:48PM -0400, Hans-Peter Nilsson wrote:
> On Thu, 28 Oct 2021, Alan Modra via Binutils wrote:
> > mmo_get_loc can return NULL.  It's commented even, and that the caller
> > then must handle a split field.  mmo_xore_* don't handle split fields,
> 
> Thanks for fixing this.  I *think* I meant that the requests
> from mmo_xore_<N>, N=(16|32|64) would be covered by the second
> clause at the comment in question; "Requests with an address
> aligned on MMO_SEC_CONTENTS_CHUNK_SIZE bytes and for no more
> than MMO_SEC_CONTENTS_CHUNK_SIZE will always get resolved."
> (MMO_SEC_CONTENTS_CHUNK_SIZE=32768) but I guess that fails for
> example if some caller is tricked into sneaking in a
> non-N-aligned vma.
> 
> > instead just segfault.  Stop that happening, and refuse to recognise
> > fuzzed mmo files that trigger this problem.
> 
> It would be nice to have test-cases covering those new code
> paths; I think I had 100% coverage at one time.  Is there a
> fuzzed object located somewhere that I can look at?

You might not be able to get at it yet, but should once the "bug" is
tested as fixed.
https://oss-fuzz.com/testcase-detail/5022516221968384

Since this was a small testcase, attached.

> I'm putting it on my todo-list, together with changing
> mmo_xore_<N> to return bool so no-one (like me) gets confused by
> the only uses of boolean use of the return-value.

Fine.  Better too.  :-)

-- 
Alan Modra
Australia Development Lab, IBM

["clusterfuzz-testcase-minimized-fuzz_nm-5022516221968384.fuzz" (application/octet-stream)]

[prev in list] [next in list] [prev in thread] [next in thread]