public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: [PATCH] readelf: handle_core_item large right shift triggers undefined behaviour.
Date: Thu, 03 Sep 2015 12:46:23 +0200	[thread overview]
Message-ID: <1441277183-29989-1-git-send-email-mjw@redhat.com> (raw)

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

The problem is this:

  int n = ffs (w);
  w >>= n;

The intent is to shift away up to (and including) the first least
significant bit in w. But w is an unsigned int, so 32 bits. And the
least significant bit could be bit 32 (ffs counts from 1). Unfortunately
a right shift equal to (or larger than) the length in bits of the left
hand operand is undefined behaviour. We expect w to be zero afterwards.
Which would terminate the while loop in the function. But since it is
undefined behaviour anything can happen. In this case, what will actually
happen is that w is unchanged, causing an infinite loop...

gcc -fsanitize=undefined will catch and warn about this when w = 0x80000000

https://bugzilla.redhat.com/show_bug.cgi?id=1259259

Signed-off-by: Mark Wielaard <mjw@redhat.com>
---
 src/ChangeLog |  4 ++++
 src/readelf.c | 12 ++++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/ChangeLog b/src/ChangeLog
index 5be1075..66f7ead 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,7 @@
+2015-09-03  Mark Wielaard  <mjw@redhat.com>
+
+	* readelf.c (handle_core_item): Handle right shift >= 32 bits.
+
 2015-08-11  Mark Wielaard  <mjw@redhat.com>
 
 	* elflint.c (check_sections): When gnuld and a NOBITS section falls
diff --git a/src/readelf.c b/src/readelf.c
index d3c2b6b..aab8b5c 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -8474,8 +8474,16 @@ handle_core_item (Elf *core, const Ebl_Core_Item *item, const void *desc,
 	    unsigned int w = negate ? ~*i : *i;
 	    while (w != 0)
 	      {
-		int n = ffs (w);
-		w >>= n;
+		/* Note that a right shift equal to (or greater than)
+		   the number of bits of w is undefined behaviour.  In
+		   particular when the least significant bit is bit 32
+		   (w = 0x8000000) then w >>= n is undefined.  So
+		   explicitly handle that case separately.  */
+		unsigned int n = ffs (w);
+		if (n < sizeof (w) * 8)
+		  w >>= n;
+		else
+		  w = 0;
 		bit += n;
 
 		if (lastbit != 0 && lastbit + 1 == bit)
-- 
2.4.3


             reply	other threads:[~2015-09-03 10:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03 10:46 Mark Wielaard [this message]
2015-09-03 20:58 Roland McGrath
2015-09-04  7:33 Mark Wielaard
2015-09-07 10:54 Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1441277183-29989-1-git-send-email-mjw@redhat.com \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).