Bug 188935 - CVE-2006-0741 kernel DoS issue
CVE-2006-0741 kernel DoS issue
Status: CLOSED DUPLICATE of bug 200034
Product: Fedora Legacy
Classification: Retired
Component: kernel (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
: Security
Depends On:
  Show dependency treegraph
Reported: 2006-04-13 15:07 EDT by James Kosin
Modified: 2007-04-18 13:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-24 18:21:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for CVE-2006-0741 (2.01 KB, patch)
2006-04-13 15:07 EDT, James Kosin
no flags Details | Diff
Ammended patch for CVE-2006-0741 (1.79 KB, patch)
2006-04-20 09:04 EDT, James Kosin
no flags Details | Diff

  None (edit)
Description James Kosin 2006-04-13 15:07:24 EDT
This effects all 2.4 kernels at the very least.

[PATCH] Always check that RIPs are canonical during signal handling master
author	Andi Kleen <ak@suse.de>
	Tue, 11 Apr 2006 10:34:45 +0000 (12:34 +0200)
committer	Marcelo Tosatti <marcelo@dmt.cnet>
	Wed, 12 Apr 2006 20:16:58 +0000 (15:16 -0500)
commit	e5a190da220758a739a31189440669c37fcd9773
tree	5ce75f4f0a50a2dba708533cb2b855f20cc2894d	tree
parent	09d3b3dcfa80c9094f1748c1be064b9326c9ef2b	commit | commitdiff
[PATCH] Always check that RIPs are canonical during signal handling

First the already existing check in COPY_CANON for sigreturn
wasn't correct. Replace it with a better check against TASK_SIZE.

Also add a check to sigaction which was missing it previously.

This works around a problem in handling non canonical RIPs on SYSRET on Intel
CPUs. They report the #GP on the SYSRET, not the next instruction
as Linux expects it. With these changes this path should never
see a non canonical user RIP.

Roughly based on a patch by Ernie Petrides, but redone by AK.

This is CVE-2006-0741

Cc: petrides@redhat.com
Signed-off-by: Andi Kleen <ak@suse.de>
arch/x86_64/kernel/signal.c 		blob | diff | history
Comment 1 James Kosin 2006-04-13 15:07:24 EDT
Created attachment 127720 [details]
Patch for CVE-2006-0741
Comment 2 David Eisenstein 2006-04-13 19:03:31 EDT
Thanks for posting this here, James, and for the patch.  The CVE says, "Linux
kernel before, when running on Intel processors, allows local users to
cause a denial of service ('endless recursive fault') via unknown attack vectors
related to a 'bad elf entry address.'"

Is this an x86_64-only condition??  Am noticing that the patch is for the x86_64
architecture kernel directory...

Potentially affects legacy kernels:

   Distro  i386?  x86_64?    Package
---------  -----  -------    ------------------------------
   RHL7.3    X               kernel-2.4.20-46.7.legacy
   RHL9      X               kernel-2.4.20-46.9.legacy
   FC1       X               kernel-2.4.22-1.2199.8.legacy.nptl
   FC2       X               kernel-2.6.10-2.3.legacy_FC2
   FC3       X       X       kernel-2.6.12-2.3.legacy_FC3

If this is i386 and x86_64, then it affects all distros we support.  If it's
x86_64 only, then it affects only FC3, as Legacy doesn't support x86_64 packages
for any other distros...
Comment 3 James Kosin 2006-04-14 08:20:36 EDT

It may be a security issue if anyone builds their own kernel for x86_64 on the 
platforms that legacy only ships i386 packages for.  From the sources provided 
by such packages.

It is just for x86_64 though.  The file patched is in that directory.

Comment 4 James Kosin 2006-04-20 09:01:30 EDT
The author is still working on the issue.  I've attached another ammended patch 
to help fix the issue.
Comment 5 James Kosin 2006-04-20 09:04:38 EDT
Created attachment 128037 [details]
Ammended patch for CVE-2006-0741

This patch goes with the last patch.  We can build a single patch when
Comment 6 Marc Deslauriers 2006-07-24 18:21:36 EDT

*** This bug has been marked as a duplicate of 200034 ***

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