Bug 112355 - (IT_56834_63078) dmidecode v2.2 does not work on IBM eServer xSeries 445
dmidecode v2.2 does not work on IBM eServer xSeries 445
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel-utils (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
:
: 128673 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-18 05:46 EST by Josef Möllers
Modified: 2007-11-30 17:06 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-19 13:28:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Core file from dmidecode run (76.00 KB, application/octet-stream)
2005-02-09 10:34 EST, Petter Reinholdtsen
no flags Details
Proposed code fix (834 bytes, patch)
2005-02-10 04:01 EST, Jean Delvare
no flags Details | Diff
correct signed/unsigned type issues. (2.34 KB, text/plain)
2005-02-10 14:52 EST, Don Howard
no flags Details

  None (edit)
Description Josef Möllers 2003-12-18 05:46:59 EST
Description of problem:
When running "dmidecode" on an IBM eServer xSeries 445, the program dies with a 
segmentation fault.

Version-Release number of selected component (if applicable):
2.2-0.1

How reproducible:
Just run "dmidecode" on an xSeries 445

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Segmentation Fault

Expected results:
Contents of Desktop Management Interface data area

Additional info:
Comment 1 Ernst-Heinrich Klaas 2004-02-05 09:09:01 EST
The problem is fixed with dmidecode v2.3.
( See also dmidecode changelog : 
  2003-10-09  Jean Delvare  <khali@linux-fr.org>
    * dmidecode.c: Fix a bug that prevented dmidecode to reach DMI
      tables beyond the 2GB memory limit. Reported by Mike Cooper. )

In addition to the segmentation fault after calling dmidecode v2.2 
direct there occur some more “strange” thinks  :
After system reboot KUDZU tries to configure a “new” mouse or 
a “keyboard timeout” will appear.
All problems are solved with dmidecode v2.3.

It is very important for all customers who are using greater server 
systems to get the new dmidecode v 2.3.

Please offer this new version via RHN as soon as even possible.

Thanks.
Comment 7 Rick Kornfeld 2005-02-03 13:32:58 EST
Hello - I am having the same problem with dmidecode 2.5. I downloaded version
2.3, recompiled and dmidecode 2.3 works correctly on the IBM 445. It looks like
the fixes in dmidecode 2.3 did not make it up the line into 2.5

Thank you
Comment 9 Don Howard 2005-02-03 14:11:00 EST
Hi Josef / Rick 

I've not been able to reproduce this prolbem on a local x445.
Could each of you collect a corefile from the crashing dmidecode and attach it
here, along with the version of kernel-utils that you are using?
Comment 12 Petter Reinholdtsen 2005-02-09 10:32:52 EST
I experience with problem on RHEL WS 3 using both /usr/sbin/dmidecode
and the latest CVS version of the dmidecode source.  The backtrace
for the CVS version look like this:

(gdb) run
Starting program: /usr/src/dmidecode/dmidecode/dmidecode
# dmidecode 2.5
SMBIOS 2.3 present.
96 structures occupying 5510 bytes.
Table at 0xDFF9C340.

Program received signal SIGSEGV, Segmentation fault.
0x001f017a in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0  0x001f017a in memcpy () from /lib/tls/libc.so.6
#1  0x0804f3ae in mem_chunk (base=-537279680, len=5510,
    devmem=0x8053b48 "/dev/mem") at util.c:136
#2  0x0804ed6f in dmi_table (base=3757687616, len=5510, num=96, 
ver=515,
    devmem=0x8053b48 "/dev/mem") at dmidecode.c:3746
#3  0x0804ef84 in smbios_decode (buf=0x9c37fe8 
"_SM_\f\037\002\003q\001",
    devmem=0x8053b48 "/dev/mem") at dmidecode.c:3796
#4  0x0804f1f0 in main (argc=1, argv=0xbfff9554) at dmidecode.c:3925
(gdb)

I'll attach a coredump from running /usr/sbin/dmidecode (copied to 
different location to get rid of suid bit.
Comment 13 Petter Reinholdtsen 2005-02-09 10:34:11 EST
Created attachment 110870 [details]
Core file from dmidecode run
Comment 14 Don Howard 2005-02-10 02:08:00 EST
In the both of the dmidecode-2.2 core files that I've looked at, it 
looks like the culprit is this: 
 
 
static void dmi_table(...) 
... 
 
#ifdef USE_MMAP 
 psize=getpagesize(); 
 mmbase=div(base, psize); 
 
 
Both base and psize are unsigned 32 bit values -- div() expects and 
returns signed arguments. 
 
This is corrected in dmidecode 2.4. 
 
 
 
 
 
It looks like a similar problem is lurking in the 2.5 implementation: 
 
void *mem_chunk(off_t base, off_t len, const char *devmem) {...} 
 
 
static void dmi_table(u32 base, u16 len, u16 num, u16 ver, const char 
*devmem) 
{ 
        ...  
 if((buf=mem_chunk(base, len, devmem))==NULL) 
         
        /* calling mem_chunk with an unsigned value  
           for (off_t)base */ 
 
 
[You can see a negative value for 'base' in frame 1 of the backtrace 
in comment#12] 
 
Comment 15 Jean Delvare 2005-02-10 03:59:51 EST
(I am the co-author and current maintainer of dmidecode.)

I think that Don Howard's analysis is correct. Passing arguments to
mem_chunk as off_t causes an unsigned to signed conversion which
breaks on machines that hold the DMI data past the 2 GB memory limit.

I am very sorry that I introduced that problem again while cleaning up
and refactoring the code for the 2.5 release, when the problem had
been fixed in 2.3.

Here is a patch against 2.5 which should hopefully fix the problem. It
simply uses size_t instead of off_t for the arguments of mem_chunk.
Please report success or failure.

If it works fine, I'll apply this to dmidecode CVS, and release 2.6
pretty soon.

I'd definitely need such a machine where the DMI data is past the 2 GB
memory limit, so that I can check that my changes don't break anything
in this particular case.

Thanks and sorry again for reintroducing that bug.
Comment 16 Jean Delvare 2005-02-10 04:01:03 EST
Created attachment 110912 [details]
Proposed code fix
Comment 17 Josef Möllers 2005-02-10 04:25:23 EST
All I can add is that my personal notes refer to an IBM XSeries 445 with 8GB of
memory which was used by our QA dept at that time. The large DMI section was
located at 0xeffac340 and the bug in 2.2 was in the use of div() (signed vs.
unsigned). Unfortunately I do not have access to such a machine any more, so I
can't offer any help.
Comment 18 Petter Reinholdtsen 2005-02-10 04:40:38 EST
I tested the patch using the 2.5 source, and it fixed the segfault.
I got sensible output from dmidecode, so I guess it work. :)

The machine got 8GiB of RAM, so I guess the problem is with machines
with lots of memory.
Comment 19 Rick Kornfeld 2005-02-10 06:49:21 EST
I still have my machine with 8 gigs so I can test it
Comment 21 Don Howard 2005-02-10 14:52:24 EST
Created attachment 110934 [details]
correct signed/unsigned type issues.

Address a couple additional signed/unsigned issues. This doesn't seem to fix
the non-mmap path, but I believe that makes things more correct.
Comment 22 Don Howard 2005-02-10 14:54:43 EST
Also, I can confirm that Jean Delvare's patch works. 
Comment 23 Jean Delvare 2005-02-11 19:04:06 EST
I have committed the relevant fixes to dmidecode CVS (this includes
some of Don Howard's suggestions). I plan to release 2.6 by the end of
February.

I'd like to thank you all for the reports, patches and feedback. This
is much appreciated. Please let me know if there's anything wrong with
the CVS version so that it can get fixed before the release.

Changes from 2.5 to (planned) 2.6:
* More code refactored.
* 2 GB limit bug fixed (again).
* BeOS and Cygwin support.
* Basic command-line handling.
Comment 25 Dave Jones 2005-02-13 02:19:27 EST
fix committed to CVS, will be in next builds.
Comment 33 Dennis Gregorovic 2005-05-19 13:28:14 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-228.html
Comment 34 Don Howard 2005-05-26 17:42:34 EDT
*** Bug 128673 has been marked as a duplicate of this bug. ***

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