Bug 134981

Summary: CAN-2004-0138 Program crashes the kernel
Product: Red Hat Enterprise Linux 3 Reporter: Bastien Nocera <bnocera>
Component: kernelAssignee: Jim Paradis <jparadis>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 3.0CC: mjc, peterm, petrides, riel, security-response-team, tao, uthomas
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: impact=important
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-02 11:36:38 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:
Attachments:
Description Flags
Patch that fixes this bug none

Description Bastien Nocera 2004-10-07 17:31:24 UTC 
Description of problem:
Kernel crash (somewhere in binfmt...)

Version-Release number of selected component (if applicable):
2.4.21-20.EL

How reproducible:
Every time

Steps to Reproduce:
1. Unzip the attached zip file
2. run the program, or
2a. run "ldd program"
  
Actual results:
Crashes the kernel

Expected results:
It just fails

Additional info:
Comment 8 Bill Nottingham 2004-10-07 21:00:02 UTC 
Under U2:

# ./crash.out
Unable to load interpreter
request_moduloe[binfmt-464c]: wiatpid(2727,...) failed, errno 512
memory.c:553: bad pgd 000001011a22d000(706d617473656d69)

However, it only hangs crash.out there, not the system.
Comment 13 Jim Paradis 2004-10-15 04:27:43 UTC 
urk... the problem is that the main binary is a 64-bit image, but it
links to a 32-bit loader and shared library (probably because it's
looking for things in /lib rather than in /lib64).  I don't know HOW
it manages to smash these different flavors together into one image,
but it does.  That's why we're going nuts in "load_elf**32**_binary()"
even though it's a 64-bit main image.

RHEL4 manages to correctly reject this mongrel binary, and it
shouldn't be hard to add similar checks to RHEL3.
Comment 14 Jim Paradis 2004-10-16 03:46:15 UTC 
Created attachment 105318 [details]
Patch that fixes this bug

I lifted this patch from 2.6; it's an extra sanity check in load_elf_binary()
to ensure that the ELF interpreter is of an arch compatible with the main
program.  I tested it and it fixes the problem.  Now when you attempt to run
the test program you get the message:

-bash: ./crash.out: Accessing a corrupted shared library
Comment 22 Ernie Petrides 2004-11-13 02:11:12 UTC 
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-25.EL).
Comment 24 Ernie Petrides 2004-11-17 21:37:28 UTC 
*** Bug 127915 has been marked as a duplicate of this bug. ***
Comment 25 Ernie Petrides 2004-11-25 01:28:02 UTC 
The fix for this problem has also been committed to the RHEL3 E4
patch pool this evening (in kernel version 2.4.21-20.0.1.EL).
Comment 26 Mark J. Cox 2004-12-02 11:36:38 UTC 
http://rhn.redhat.com/errata/RHSA-2004-549.html
Comment 28 Marcel Holtmann 2006-05-31 13:23:34 UTC 
The correct CVE name for this issue is CVE-2004-0138.