Bug 220817 - signed overflow in compare_modules
Summary: signed overflow in compare_modules
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: elfutils (Show other bugs)
(Show other bugs)
Version: 5.0
Hardware: x86_64 Linux
Target Milestone: ---
: ---
Assignee: Roland McGrath
QA Contact: David Lawrence
Depends On:
Blocks: 215053
TreeView+ depends on / blocked
Reported: 2006-12-27 14:29 UTC by Frank Ch. Eigler
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: 0.125-3.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-06 00:23:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Frank Ch. Eigler 2006-12-27 14:29:41 UTC
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;
    return 0;

Comment 1 Ulrich Drepper 2006-12-29 20:38:50 UTC
Applied upstream.  Will be in 0.125.

Comment 4 Frank Ch. Eigler 2007-01-12 15:25:09 UTC
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-14 03:52:43 UTC
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-06 00:23:46 UTC
0.125 went into RHEL5.

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