Bug 134981 - CAN-2004-0138 Program crashes the kernel
Summary: CAN-2004-0138 Program crashes the kernel
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Jim Paradis
QA Contact: Brian Brock
Whiteboard: impact=important
Keywords: Security
: 127915 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-07 17:31 UTC by Bastien Nocera
Modified: 2007-11-30 22:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-02 11:36:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch that fixes this bug (567 bytes, patch)
2004-10-16 03:46 UTC, Jim Paradis
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:549 normal SHIPPED_LIVE Important: kernel security update 2004-12-02 05:00:00 UTC

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):

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

Comment 28 Marcel Holtmann 2006-05-31 13:23:34 UTC
The correct CVE name for this issue is CVE-2004-0138.

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