Bug 493345
Summary: | Buffer overrun on device name printing 'sar -p -d 1' on 64 bit machines | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Issue Tracker <tao> |
Component: | sysstat | Assignee: | Ivana Varekova <varekova> |
Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 4.7 | CC: | benl, ddumas, mpoole, rvokal, syeghiay, tao |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-02-16 14:06:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Issue Tracker
2009-04-01 14:11:29 UTC
Description of problem: Customer can see inconsistent output with the "sar -p -d 1" command. The output of this command is different on a RHEL 4 32bit system and on RHEL 4 64 bit system. On a RHEL 4 32bit machine the DEV column of the output shows correct device names (ram0,hda1 etc) but on a RHEL 4 64 bit machine it only shows numbers (0,1 etc ). Customer wants to know why there is a difference in the output and if its a bug. How reproducible: Steps to Reproduce: I have reproduced this issue on a RHEL 4 system running the current kernel and updated sysstat package. Kernel : 2.6.9-78.0.17.EL sysstat : 5.0.5-19.el4 On a RHEL 4 32 bit system: #[root@dhcp6-146 ~]# sar -p -d 1 Linux 2.6.9-78.0.17.EL (dhcp6-146.pnq.redhat.com) 03/27/2009 01:14:51 PM DEV tps rd_sec/s wr_sec/s 01:14:52 PM ram0 0.00 0.00 0.00 01:14:52 PM ram1 0.00 0.00 0.00 01:14:52 PM ram2 0.00 0.00 0.00 ... 01:14:52 PM hda 0.00 0.00 0.00 01:14:52 PM hda1 0.00 0.00 0.00 01:14:52 PM hda2 0.00 0.00 0.00 ... On a RHEL 4 64 bit system: [root@dhcp7-180 ~]# sar -p -d 1 Linux 2.6.9-78.0.17.EL (dhcp7-180.pnq.redhat.com) 03/27/2009 05:34:25 PM DEV tps rd_sec/s wr_sec/s 05:34:26 PM 0 0.00 0.00 0.00 05:34:26 PM 1 0.00 0.00 0.00 05:34:26 PM 2 0.00 0.00 0.00 ... 05:34:26 PM a 1.02 16.33 0.00 05:34:26 PM a1 0.00 0.00 0.00 05:34:26 PM a2 1.02 16.33 0.00 ... Please find attached complete outputs. Actual results: Output of the "sar -p -d 1 " shows only numbers on the 64 bit system whereas shows correct device names on 32 bit system Expected results: Outputs on both 32 bit and 64 bit RHEL 4 systems should be identical. i.e the DEV column should show correct device names (ram0,hda1 etc) Additional info: This behavior is only visible on a RHEL 4 system 64 bit system. RHEL 5 on 32 and 64 bit machines show correct output. I checked "man sar" and found the following comment for the "-p" option: <snip> Pretty-print device names. By default names are printed as devn-m where n and m are the major and minor numbers for the device. Use of this option displays the names of the devices as they (should) appear in /dev. Name mappings are con- trolled by /etc/sysconfig/sysstat.ioconf. </snip> But the file /etc/sysconfig/sysstat.ioconf is identical on both 32 & 64 bit systems. This event sent from IssueTracker by mpoole [Support Engineering Group] issue 280142 After some debugging have tracked it ioc_conv in common.c overrunning the "out" buffer due to incorrectly defined length. Fix was included upstream 2005/11/28: Version 6.0.2 - Sebastien Godard (sysstat <at> wanadoo.fr) * Off-by-one error in ioc_conv which was corrupting device names on 64-bit architecture [Debian bug #334305]. Just needs to change definition of "out", was static char out[16]; should be static char out[17]; Since any buffer overrun has possible unintended consequences other than the symptoms already noted I am marking this as a blocker. 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 therefore 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-2011-0224.html |