Bug 112355 (IT_56834_63078)

The problem is fixed with dmidecode v2.3.
( See also dmidecode changelog : 
  2003-10-09  Jean Delvare  <khali>
    * 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.

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

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?

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.

Created attachment 110870 [details]
Core file from dmidecode run

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] 
 

(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.

Created attachment 110912 [details]
Proposed code fix

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.

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.

I still have my machine with 8 gigs so I can test it

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.

Also, I can confirm that Jean Delvare's patch works. 

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.

fix committed to CVS, will be in next builds.

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

*** Bug 128673 has been marked as a duplicate of this bug. ***