Bug 220817 - signed overflow in compare_modules
signed overflow in compare_modules
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: elfutils (Show other bugs)
5.0
x86_64 Linux
high Severity medium
: ---
: ---
Assigned To: Roland McGrath
David Lawrence
:
Depends On:
Blocks: 215053
  Show dependency treegraph
 
Reported: 2006-12-27 09:29 EST by Frank Ch. Eigler
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.125-3.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-05 19:23:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Ch. Eigler 2006-12-27 09:29:41 EST
In elfutils 0.124, libdwfl's compare_modules routine screws up for
x86_64.  The problem is that the kernel pseudo-module's address gets
compared incorrectly to module addresses, and is consequently not
correctly sorted in the dwfl->modules array.

The following simpler implementation works and explains:

static int
compare_modules (const void *a, const void *b)
{
  Dwfl_Module *const *p1 = a, *const *p2 = b;
  const Dwfl_Module *m1 = *p1, *m2 = *p2;
  if (m1 == NULL)
    return -1;
  if (m2 == NULL)
    return 1;

  // NB: Computing a signed difference between m1-> and m2-> is not
  // good enough, since the possible range of the difference exceeds
  // the representational limits of signed numbers of the same
  // bit-width.
  //
  // e.g: take 8-bit values.
  // m1=255 m2=0 => m1 larger, should return 1, but (signed char) (255-0) = -1 !

  if (m1->low_addr < m2->low_addr)
    return -1;
  else if (m1->low_addr > m2->low_addr)
    return 1;
  else
    return 0;
}
Comment 1 Ulrich Drepper 2006-12-29 15:38:50 EST
Applied upstream.  Will be in 0.125.
Comment 4 Frank Ch. Eigler 2007-01-12 10:25:09 EST
Can you give a larger blurb to justify treating this as an exception to PM?
Should this be tied to bug #215053?
Comment 5 Roland McGrath 2007-01-13 22:52:43 EST
Two fixes in elfutils-0.125, including this one, are necessary to resolve bug
215053.  This one's urgency and impact should be considered the same as bug
215053, whatever that determination is.  This elfutils issue does not have any
significant impact outside its impact on systemtap.
Comment 6 Roland McGrath 2007-02-05 19:23:46 EST
0.125 went into RHEL5.

Note You need to log in before you can comment on or make changes to this bug.