Bug 486328 - Incorrect command name from the core file
Incorrect command name from the core file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: file (Show other bugs)
5.3
All Linux
urgent Severity medium
: rc
: ---
Assigned To: Jan Kaluža
BaseOS QE
: ZStream
Depends On:
Blocks: 497163
  Show dependency treegraph
 
Reported: 2009-02-19 07:50 EST by Tomas Smetana
Modified: 2012-10-31 05:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: 64-bit Linux core file has printable characters in the PRPSINFO NOTE section at the offset where FreeBSD stores the command name. File than thought it's the valid offset to get the command name from. Consequence: This caused File to print bad command name ("from ' N'") for particular core files. Fix: The offset where FreeBSD stores the command name is checked only when the core file was generated on FreeBSD platfrom. Result: File does not try to get command name from FreeBSD offset if the core file is not created on FreeBSD and detects core file command name on 64bit Linux properly.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 00:45:29 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)
Compressed testing core file (10.26 KB, application/octet-stream)
2009-02-19 07:51 EST, Tomas Smetana
no flags Details
Proposed patch (814 bytes, patch)
2009-02-19 07:54 EST, Tomas Smetana
no flags Details | Diff
New patch (448 bytes, patch)
2009-02-23 04:21 EST, Tomas Smetana
no flags Details | Diff
More complex patch (1.10 KB, patch)
2009-02-24 08:27 EST, Tomas Smetana
no flags Details | Diff
the latest, cleanest version of the patch (987 bytes, patch)
2009-04-02 05:14 EDT, Daniel Novotny
no flags Details | Diff

  None (edit)
Description Tomas Smetana 2009-02-19 07:50:50 EST
Description of problem:
The file command can report a wrong command name on certain ELF core files.

Version-Release number of selected component (if applicable):
file-4.17-15

How reproducible:
always

Steps to Reproduce:
1. run file command on the attached core file
  
Actual results:
core.19858: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from ' N'

Expected results:
core.19858: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'sleep'

Additional info:
The core file was generated on an x86-64 system (reported also on IA-64) this way:
1. useradd -u 20000 hoge
2. su - hoge
3. ulimit -c unlimited
4. sleep 1d &
5. kill -6 <pid of the sleep command>

The problem is caused by the fact that the 64-bit Linux core file has printable characters in the PRPSINFO NOTE section at the offset where FreeBSD stores the command name.  Probing the offsets in reversed order fixes the issue.
Comment 1 Tomas Smetana 2009-02-19 07:51:38 EST
Created attachment 332548 [details]
Compressed testing core file
Comment 2 Tomas Smetana 2009-02-19 07:54:51 EST
Created attachment 332549 [details]
Proposed patch

Reverse the order of probed PRPSINFO offsets.  Similar change is already present in the newer upstream versions.
Comment 3 Daniel Novotny 2009-02-19 09:04:43 EST
thanks for the patch, it really did the trick
Comment 4 Tomas Smetana 2009-02-20 03:20:03 EST
Comment on attachment 332549 [details]
Proposed patch

The patch is incorrect -- the strings areas may overlap and a longer command is then detected incorrectly.
Comment 5 Tomas Smetana 2009-02-20 03:24:29 EST
The patch in comment #2 was taken from the upstream sources but even the new file-5.00 would fail in the following case:

1. bash -c "sleep 1d;echo 11111111111111111111111111111111111111112345678901234567890" &
2. kill -6 <pid of the previous command>
3. file <produced coredump>

Result:
core.12332: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from '11111123456789012345678'
Comment 6 Tomas Smetana 2009-02-23 04:21:46 EST
Created attachment 332913 [details]
New patch

This patch was suggested by Masahiro Matsuya.  It does not bring in the regression.  It just assumes that the command string can't start with a space which is enough to fix the observed problem (the string detected at FreeBSD offset was always " N").
Comment 7 Tomas Smetana 2009-02-24 08:27:59 EST
Created attachment 333042 [details]
More complex patch

I was wrong -- there could appear another printable character not just a space at the FreeBSD offset.  Therefore the previous patch is also wrong.

Here's another attempt:

I have modified the upstream patch: let's check the offsets from the large one but don't print out the first string found.  Probe also one character before the matched offset and the first character at the lower offset and if they both conform to the criteria continue guessing.  This way we should find the highest matching offset avoiding false positives caused by long command lines.
Comment 8 Daniel Novotny 2009-02-26 09:57:54 EST
I have made some core dumps in freebsd

http://people.fedoraproject.org/~dnovotny/bsdcores.zip

and it seems they are detected as "os_style == OS_STYLE_FREEBSD",
so they are this way distinguishable from Linux core dumps and
can (or rather have to) be treated separately in the case
when you print the coredump commandline
Comment 10 RHEL Product and Program Management 2009-03-26 12:58:45 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 12 Daniel Novotny 2009-04-02 05:14:01 EDT
Created attachment 337754 [details]
the latest, cleanest version of the patch

we found BSD core files can go in another case, can be left off the cycle and not confuse the analysis of linux core files
Comment 15 Daniel Novotny 2009-04-22 06:12:55 EDT
fixed in file-4.17-16
Comment 27 Jan Kaluža 2012-01-05 07:07:04 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: 64-bit Linux core file has printable characters in the PRPSINFO NOTE section at the offset where FreeBSD stores the
command name. File than thought it's the valid offset to get the command name from.

Consequence: This caused File to print bad command name ("from ' N'") for particular core files.

Fix: The offset where FreeBSD stores the command name is checked only when the core file was generated on FreeBSD platfrom.

Result: File does not try to get command name from FreeBSD offset if the core file is not created on FreeBSD and detects core file command name on 64bit Linux properly.
Comment 28 errata-xmlrpc 2012-02-21 00:45:29 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0201.html

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