public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* asan: mmo: NULL dereferenc in mmo_xore_32
@ 2021-10-28  3:51 Alan Modra
  2021-10-28 22:38 ` Hans-Peter Nilsson
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2021-10-28  3:51 UTC (permalink / raw)
  To: binutils

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,
instead just segfault.  Stop that happening, and refuse to recognise
fuzzed mmo files that trigger this problem.

	* mmo.c (mmo_get_loc): Don't declare inline.
	(mmo_xore_64, mmo_xore_32, mmo_xore_16): Remove forward decls.
	Return pointer, don't dereference NULL.
	(mmo_scan): Return error on mmo_get_loc returning NULL.

diff --git a/bfd/mmo.c b/bfd/mmo.c
index cb018a1c275..2ee386662a4 100644
--- a/bfd/mmo.c
+++ b/bfd/mmo.c
@@ -382,10 +382,7 @@ static bool mmo_scan (bfd *);
 static asection *mmo_decide_section (bfd *, bfd_vma);
 static asection *mmo_get_generic_spec_data_section (bfd *, int);
 static asection *mmo_get_spec_section (bfd *, int);
-static inline bfd_byte *mmo_get_loc (asection *, bfd_vma, int);
-static void mmo_xore_64 (asection *, bfd_vma vma, bfd_vma value);
-static void mmo_xore_32 (asection *, bfd_vma vma, unsigned int);
-static void mmo_xore_16 (asection *, bfd_vma vma, unsigned int);
+static bfd_byte *mmo_get_loc (asection *, bfd_vma, int);
 static bfd_cleanup mmo_object_p (bfd *);
 static void mmo_map_set_sizes (bfd *, asection *, void *);
 static bool mmo_get_symbols (bfd *);
@@ -741,38 +738,50 @@ mmo_decide_section (bfd *abfd, bfd_vma vma)
 
 /* Xor in a 64-bit value VALUE at VMA.  */
 
-static inline void
+static inline bfd_byte *
 mmo_xore_64 (asection *sec, bfd_vma vma, bfd_vma value)
 {
   bfd_byte *loc = mmo_get_loc (sec, vma, 8);
-  bfd_vma prev = bfd_get_64 (sec->owner, loc);
+  if (loc)
+    {
+      bfd_vma prev = bfd_get_64 (sec->owner, loc);
 
-  value ^= prev;
-  bfd_put_64 (sec->owner, value, loc);
+      value ^= prev;
+      bfd_put_64 (sec->owner, value, loc);
+    }
+  return loc;
 }
 
 /* Xor in a 32-bit value VALUE at VMA.  */
 
-static inline void
+static inline bfd_byte *
 mmo_xore_32 (asection *sec, bfd_vma vma, unsigned int value)
 {
   bfd_byte *loc = mmo_get_loc (sec, vma, 4);
-  unsigned int prev = bfd_get_32 (sec->owner, loc);
+  if (loc)
+    {
+      unsigned int prev = bfd_get_32 (sec->owner, loc);
 
-  value ^= prev;
-  bfd_put_32 (sec->owner, value, loc);
+      value ^= prev;
+      bfd_put_32 (sec->owner, value, loc);
+    }
+  return loc;
 }
 
 /* Xor in a 16-bit value VALUE at VMA.  */
 
-static inline void
+static inline bfd_byte *
 mmo_xore_16 (asection *sec, bfd_vma vma, unsigned int value)
 {
   bfd_byte *loc = mmo_get_loc (sec, vma, 2);
-  unsigned int prev = bfd_get_16 (sec->owner, loc);
+  if (loc)
+    {
+      unsigned int prev = bfd_get_16 (sec->owner, loc);
 
-  value ^= prev;
-  bfd_put_16 (sec->owner, value, loc);
+      value ^= prev;
+      bfd_put_16 (sec->owner, value, loc);
+    }
+  return loc;
 }
 
 /* Write a 32-bit word to output file, no lop_quote generated.  */
@@ -1472,7 +1481,7 @@ SUBSECTION
    If there's new contents, allocate to the next multiple of
    MMO_SEC_CONTENTS_CHUNK_SIZE.  */
 
-static inline bfd_byte *
+static bfd_byte *
 mmo_get_loc (asection *sec, bfd_vma vma, int size)
 {
   bfd_size_type allocated_size;
@@ -1647,7 +1656,11 @@ mmo_scan (bfd *abfd)
 	      vma &= ~3;
 	      if (sec == NULL)
 		sec = bfd_make_section_old_way (abfd, MMO_TEXT_SECTION_NAME);
-	      mmo_xore_32 (sec, vma, bfd_get_32 (abfd, buf));
+	      if (!mmo_xore_32 (sec, vma, bfd_get_32 (abfd, buf)))
+		{
+		  bfd_set_error (bfd_error_bad_value);
+		  goto error_return;
+		}
 	      vma += 4;
 	      lineno++;
 	      break;
@@ -1738,7 +1751,11 @@ mmo_scan (bfd *abfd)
 		fixosec = mmo_decide_section (abfd, p);
 		if (fixosec == NULL)
 		  goto error_return;
-		mmo_xore_64 (fixosec, p, vma);
+		if (!mmo_xore_64 (fixosec, p, vma))
+		  {
+		    bfd_set_error (bfd_error_bad_value);
+		    goto error_return;
+		  }
 	      }
 	    break;
 
@@ -1750,7 +1767,11 @@ mmo_scan (bfd *abfd)
 		asection *fixrsec = mmo_decide_section (abfd, p);
 		if (fixrsec == NULL)
 		  goto error_return;
-		mmo_xore_16 (fixrsec, p, yz);
+		if (!mmo_xore_16 (fixrsec, p, yz))
+		  {
+		    bfd_set_error (bfd_error_bad_value);
+		    goto error_return;
+		  }
 	      }
 	    break;
 
@@ -1813,7 +1834,11 @@ mmo_scan (bfd *abfd)
 		fixrsec = mmo_decide_section (abfd, vma);
 		if (fixrsec == NULL)
 		  goto error_return;
-		mmo_xore_32 (fixrsec, p, delta);
+		if (!mmo_xore_32 (fixrsec, p, delta))
+		  {
+		    bfd_set_error (bfd_error_bad_value);
+		    goto error_return;
+		  }
 	      }
 	    break;
 
@@ -1937,6 +1962,11 @@ mmo_scan (bfd *abfd)
 		    rsec->flags |= SEC_LINKER_CREATED;
 		    rsec->vma = z * 8;
 		    loc = mmo_get_loc (rsec, z * 8, (255 - z) * 8);
+		    if (!loc)
+		      {
+			bfd_set_error (bfd_error_bad_value);
+			goto error_return;
+		      }
 		    bfd_put_64 (abfd, first_octa, loc);
 
 		    for (i = z + 1; i < 255; i++)
@@ -2041,7 +2071,11 @@ mmo_scan (bfd *abfd)
 	  /* This wasn't a lopcode, so store it in the current section.  */
 	  if (sec == NULL)
 	    sec = bfd_make_section_old_way (abfd, MMO_TEXT_SECTION_NAME);
-	  mmo_xore_32 (sec, vma & ~3, bfd_get_32 (abfd, buf));
+	  if (!mmo_xore_32 (sec, vma & ~3, bfd_get_32 (abfd, buf)))
+	    {
+	      bfd_set_error (bfd_error_bad_value);
+	      goto error_return;
+	    }
 	  vma += 4;
 	  vma &= ~3;
 	  lineno++;

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: asan: mmo: NULL dereferenc in mmo_xore_32
  2021-10-28  3:51 asan: mmo: NULL dereferenc in mmo_xore_32 Alan Modra
@ 2021-10-28 22:38 ` Hans-Peter Nilsson
  2021-10-28 23:47   ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: Hans-Peter Nilsson @ 2021-10-28 22:38 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

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?

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.

>
> 	* mmo.c (mmo_get_loc): Don't declare inline.

Yeah, it got a little bit too bit for that...  IMHO inline on
static functions is a little bit presumptious these days.
I'll just drop them altogether.

> 	(mmo_xore_64, mmo_xore_32, mmo_xore_16): Remove forward decls.
> 	Return pointer, don't dereference NULL.
> 	(mmo_scan): Return error on mmo_get_loc returning NULL.

brgds, H-P

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: asan: mmo: NULL dereferenc in mmo_xore_32
  2021-10-28 22:38 ` Hans-Peter Nilsson
@ 2021-10-28 23:47   ` Alan Modra
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Modra @ 2021-10-28 23:47 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: binutils

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

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

[-- Attachment #2: clusterfuzz-testcase-minimized-fuzz_nm-5022516221968384.fuzz --]
[-- Type: application/octet-stream, Size: 2508 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-28 23:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-28  3:51 asan: mmo: NULL dereferenc in mmo_xore_32 Alan Modra
2021-10-28 22:38 ` Hans-Peter Nilsson
2021-10-28 23:47   ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).