Bug 199440 - (CVE-2006-3635) VUL-0: CVE-2006-3635: kernel: local denial-of-service on Itanium
(CVE-2006-3635)
VUL-0: CVE-2006-3635: kernel: local denial-of-service on Itanium
Status: RESOLVED WONTFIX
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
IA64 Other
: P5 - None : Normal
: ---
Assigned To: Andreas Schwab
Security Team bot
kernel:sles9 kernel:sles8 kernel:sle1...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-15 10:38 UTC by Thomas Biege
Modified: 2019-05-01 14:48 UTC (History)
9 users (show)

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


Attachments
p.diff (8.86 KB, patch)
2006-08-15 10:39 UTC, Thomas Biege
Details | Diff
Patch for 2.4.21 (3.83 KB, patch)
2006-08-16 18:39 UTC, Tony Luck
Details | Diff
Patch for 2.6.16.21 (SLES10) (6.92 KB, patch)
2006-08-18 14:30 UTC, Raymund Will
Details | Diff
bug199440_sles9sp3.diff (5.34 KB, patch)
2006-09-19 06:30 UTC, Thomas Biege
Details | Diff
bug199440_sles10.diff (5.48 KB, patch)
2006-09-19 06:31 UTC, Thomas Biege
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Biege 2006-08-15 10:38:19 UTC
Here we go...

From: "Luck, Tony" <tony.luck@intel.com>
To: vendor-sec@lst.de
Subject: [vendor-sec] Local denial of service vulnerability for Itanium/Linux
Errors-To: vendor-sec-admin@lst.de
Date: Mon, 14 Aug 2006 14:03:33 -0700

[Mailed to security@kernel.org a couple of hours ago ... Greg
 kindly pointed out that this really belongs on this list].

A user mode code sequence has been found that can crash Linux
running on an Itanium system.  I have included the patch that
detects this situation and prevents the user from crashing the
kernel.  I intend to ship this upstream to Linus when he
returns from his vacation, so this will be included in the
next 2.6.18-rc release (or 2.6.18 itself if there are no more
-rc releases).

I'm announcing here to give Linux distibutors the opportunity
to incorporate this fix at the same time.  Other operating
system vendors that may be affected are being contacted by
other people at Intel.

Questions to me: tony.luck@intel.com

[If the question is: "What is the code sequence?", then the
answer is that Intel is not releasing it. Sorry.]

-Tony

commit 7e6486b7758c1405a697bd5648f9bd0a67fc7d13
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon Aug 14 10:50:51 2006 -0700

    [IA64] Workaround for RSE issue

    Problem: An application violating the architectural rules regarding
    operation dependencies and having specific Register Stack Engine (RSE)
    state at the time of the violation, may result in an illegal operation
    fault and invalid RSE state.  Such faults may initiate a cascade of
    repeated illegal operation faults within OS interruption handlers.
    The specific behavior is OS dependent.

    Implication: An application causing an illegal operation fault with
    specific RSE state may result in a series of illegal operation faults
    and an eventual OS stack overflow condition.

    Workaround: OS interruption handlers that switch to kernel backing
    store implement a check for invalid RSE state to avoid the series
    of illegal operation faults.

    The core of the workaround is the RSE_WORKAROUND code sequence
    inserted into each invocation of the SAVE_MIN_WITH_COVER and
    SAVE_MIN_WITH_COVER_R19 macros.  This sequence includes hard-coded
    constants that depend on the number of stacked physical registers
    being 96.  The rest of this patch consists of code to disable this
    workaround should this not be the case (with the presumption that
    if a future Itanium processor increases the number of registers, it
    would also remove the need for this patch).

    Signed-off-by: Tony Luck <tony.luck@intel.com>
Comment 1 Thomas Biege 2006-08-15 10:39:10 UTC
Created attachment 96093 [details]
p.diff
Comment 5 Raymund Will 2006-08-16 09:29:51 UTC
Tony, would you mind to review the patches I'm about to prepare for
our "older" kernels?
Or do you (per chance ;) have patches for 2.6.5+ and 2.4.21+ at hand?
Comment 6 Marcus Meissner 2006-08-16 11:49:52 UTC
CVE-2006-3635
Comment 7 Tony Luck 2006-08-16 15:51:23 UTC
I'm almost done with a version of the patch for another OSDs older kernel (2.4.21-47.EL).  I'll post it to vendor-sec (probably later today).

I can take a look at 2.6.5 too.
Comment 8 Tony Luck 2006-08-16 18:39:34 UTC
Created attachment 96282 [details]
Patch for 2.4.21

Patch for 2.4.21.  Very lightly tested (boots & my test cases no longer crash the kernel).
Comment 9 Raymund Will 2006-08-18 14:30:52 UTC
Created attachment 96529 [details]
Patch for 2.6.16.21 (SLES10)

Attachment #96093 [details] with minor modification to apply to SLES10_GA_BRANCH.
(i.e. no '__init' for 'ia64_patch_mckinley_e9()')
Comment 10 Raymund Will 2006-08-18 14:32:28 UTC
Andreas, please take over from here...
CU in two weeks!  (c:
Comment 11 Thomas Biege 2006-08-21 09:03:25 UTC
From: Willy Tarreau <w@1wt.eu>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: dann frazier <dannf@debian.org>, Marcel Holtmann <holtmann@redhat.com>,
        vendor-sec@lst.de
Subject: Re: [vendor-sec] Local denial of service vulnerability forItanium/Linux CVE-2006-3635
User-Agent: Mutt/1.5.11
Errors-To: vendor-sec-admin@lst.de
Date: Sat, 19 Aug 2006 08:23:49 +0200

On Wed, Aug 16, 2006 at 02:50:46PM -0700, Luck, Tony wrote:
> On Tue, Aug 15, 2006 at 10:17:30AM -0600, dann frazier wrote:
> > Debian supports a 2.4.27-based kernel - a patch against the current
> > Bjorn tree should suffice.  Thanks Tony.
>
> Current Bjorn tree is 2.4.29.  Here's the patch against that (almost
> identical to the 2.4.21 version posted earlier ... only change is
> that the "#define rARPFS r26" and "#define rARRSC r27" were removed
> from minstate.h sometime between 2.4.21 and 2.4.29, so this version
> of the patch uses the unobfuscated register numbers.)
>
> -Tony

I've queued this one for 2.4-mainline with the detailed explanation you
provided for 2.4.21-47.

Thanks Tony!
Willy

_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Comment 12 Marcus Meissner 2006-08-23 08:39:00 UTC
With the SCTP bug being public we will not wait
with the current kernel update until the 29th of August.
Comment 13 Andreas Schwab 2006-08-23 14:25:52 UTC
What does that mean?
Comment 14 Tony Luck 2006-08-23 16:20:12 UTC
Additional note ... I posted a status update to vendor-sec yesterday.  Additional testing of the workaround that I posted has shown that it sometimes fails to recover (about 1 time in 30) on the current base kernel (2.6.18-rc4) with one of the test cases.  I think that SLES10 looks enough like the upstream kernel that it will be similarly affected.

Worse still, my backport for SLES9 (2.6.5 kernel) *always* fails on this same test case.

I requested that the embargo date be extended until after this issue is resolved.  It sound like you have some other pressing fix (comment#12 above) that needs to go out ... right now I have no new date for this issue, so you may want to go ahead with that one.  This issue will have to wait for the next train :-(
Comment 15 Marcus Meissner 2006-08-24 08:46:54 UTC
Checkin deadline is today (Aug 24) 17:00 CEST.

If this patch is not ready then, we take it for the round after the current one.
Comment 16 Thomas Biege 2006-09-19 06:30:50 UTC
Created attachment 99026 [details]
bug199440_sles9sp3.diff

maybe superfluous
Comment 17 Thomas Biege 2006-09-19 06:31:13 UTC
Created attachment 99027 [details]
bug199440_sles10.diff

maybe superfulous
Comment 18 Tony Luck 2006-09-19 15:51:59 UTC
Above attachment (in comment#17) is the new and improved version (i.e. it actually works).  Please disregard earlier patches.  The critical change is the re-initialization of ar.bspstore from r22 at the end of the workaround.
Comment 19 Thomas Biege 2006-09-26 06:56:48 UTC
From: "Luck, Tony" <tony.luck@intel.com>
To: vendor-sec@lst.de
Subject: [vendor-sec] CVE-2006-3635
Errors-To: vendor-sec-admin@lst.de
Date: Mon, 25 Sep 2006 17:12:47 -0700

No definitive news from the other OSs on whether October 5th
will work as an embargo date ... so I'm putting this back on
hold again :-(

One new thing did show up in their review ... the Linux
patches I posted here have an off-by-one error in the
calculation of the maximum legal RSE frame size.  The
        cmp.ge p6,p7=32,r17
should actually compare with "33", not with 32.  This error
didn't show up in my Linux testing because Linux always
aligns ar.bspstore on a 16-byte address, and the 32 vs. 33
here only affects the outcome in one of the 8mod16 cases
which can never occur on Linux (if a bug can never trigger
is it still a bug?)

-Tony

_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
~
Comment 20 Marcus Meissner 2006-10-27 09:46:25 UTC
the patch is not yet in kernel-source HEAD (SLES8).

please apply.
Comment 21 Andreas Schwab 2006-10-27 10:56:34 UTC
Does it actually work yet?
Comment 22 Tony Luck 2006-10-27 16:10:07 UTC
The Linux patch works ... there have been some issues on other operating systems that we had difficulty understanding (particularly as Linux didn't have the issues when running the exact same code sequence!).  I heard on Wednesday that this difference was now understood (turned out to be another side effect of the "align ar.bspstore on 16-byte boundary" that also meant that Linux hadn't noticed the off-by one problem that I described above in comment#19). So, I expect that at the status meeting that I have at 2pm PDT this afternoon we'll finally get the go-ahead to unfreeze this.  Watch out for an announcement on vendor-sec.
Comment 23 Tony Luck 2006-10-27 21:41:30 UTC
All the other OS's were told about the findings yesterday, and some of them aren't using the 16-byte aligned ar.bspstore, so they need to make changes.  We're giving them a few days to make the changes and validate them.  New plan is that I'll announce on vendor-sec on Wednesday Nov 1st that the embargo date will be Tuesday November 7th.

Unless someone finds something new while implementing changes to the fix.
Comment 24 Andreas Schwab 2006-10-30 12:28:16 UTC
The patch does not fit to our kernel.
Comment 25 Tony Luck 2006-10-30 19:01:40 UTC
Which version of the kernel?  Thomas captured two of my patches (one for sles9sp3, and one for sles10) from the vendor-sec mailing list and attached them to this bugzilla.  Both of them need to change 32 to 33 in the "cmp.ge p6,p7 = 32,r17" line.

Have you made other changes to minstate.h since I created these patches?
Comment 26 Andreas Schwab 2006-10-31 12:27:56 UTC
Just leaving out the first hunk appears to work fine.
Comment 27 Tony Luck 2006-10-31 16:57:37 UTC
I'm confused.  The first hunk of the patch adds the WORKAROUND argument to the definition of the DO_SAVE_MIN() macro.  Leaving that out should give errors when it is used (extra arg is added in the invocations of this macro in the last hunk).
Comment 28 Marcus Meissner 2006-11-23 13:08:53 UTC
any update here? 

slot for next kernel update is closing today.
Comment 29 Andreas Schwab 2006-11-23 13:16:00 UTC
What is the status of the patches?  "maybe superfluous" does not look promising.
Comment 30 Marcus Meissner 2006-11-28 12:22:57 UTC
andreas applied them apparently, so marking them up in whiteboard
Comment 31 Tony Luck 2006-11-28 18:31:23 UTC
Does this mean that these patches are visible (or will shortly become visible) in some external "kernel-of-the-day" tree?
Comment 32 Marcus Meissner 2006-11-29 08:58:29 UTC
actually yes.

either this way, or we take it out of this kernel update
and publish them next February or March.
Comment 33 Marcus Meissner 2006-11-29 10:54:43 UTC
is there still an embargo and if yes, when does it end?
Comment 34 Tony Luck 2006-11-29 16:43:05 UTC
Yes, there is still an embargo.
I still don't have a firm end date for it.  I've been told "in about another two weeks" for a long, long time :-(  New questions keep coming up as more OS vendors and OEMs look at this (and they are good questions, they deserve investigation ... one of them will require another small change to the patch for a potential issue).
Comment 35 Marcus Meissner 2006-11-29 16:47:38 UTC
Andreas, can you remove the patch again please and the changes entry :(
Comment 36 Andreas Schwab 2006-11-29 16:57:42 UTC
Ok.
Comment 37 Marcus Meissner 2007-02-09 11:01:23 UTC
this is now 6 months old.

can we come to a conclusion?
Comment 40 Tony Luck 2007-02-09 19:02:02 UTC
Another way to exploit this illegal instruction sequence showed up during our discussions with other OS vendors and OEMS.  Our first attempts at workarounds will have a significant performance impact for Linux ... so we are re-evaluating our options (to find the least bad path to move forward ... none of the options are good):

1) Deploy a complete fix that has significant negative perform impact.
2) Deploy a partial fix that covers most cases with only slight performance impact, but leave some vulnerability.
3) Deploy no fix

We obviously don't like option 1.

We don't like option 2 because it raises the risk factor (might encourage bad guys to search for the illegal instruction sequence, and in doing so they might discover the gaps in the deployed fix).

Which leaves option 3 as the least-bad path (at the moment).
Comment 41 Marcus Meissner 2007-05-22 11:06:05 UTC
any further updates?
Comment 42 Tony Luck 2007-05-22 17:32:33 UTC
Intel is sticking with the least-bad option ... deploy no fix.  In the unlikely event that this is seen in the wild, we will obviously have to act, but we see this as improbable.
Comment 43 Thomas Biege 2007-09-04 12:26:20 UTC
Should we close this bug report?
Comment 44 Tony Luck 2007-09-05 07:49:55 UTC
Do you have a "no fix planned" status (perhaps "WONT FIX"?).  That would be the most appropriate status.  Otherwise it is up to you whether to close an unfixed bug.
Comment 45 Thomas Biege 2007-09-05 07:55:57 UTC
closing
Comment 46 Bugzilla Account Maintenance 2008-09-02 18:07:46 UTC
Because the LATER and REMIND resolutions have been removed, the resolution of this bug has changed from LATER to WONTFIX. If this bug needs to be reconsidered, reopen it and set a future "Target Milestone for Fix."
Comment 47 Marcus Meissner 2017-08-02 08:22:57 UTC
It seems this was fixed in 2008.

commit 4dcc29e1574d88f4465ba865ed82800032f76418
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue May 27 13:23:16 2008 -0700

    [IA64] Workaround for RSE issue
    
    Problem: An application violating the architectural rules regarding
    operation dependencies and having specific Register Stack Engine (RSE)
    state at the time of the violation, may result in an illegal operation
    fault and invalid RSE state.  Such faults may initiate a cascade of
    repeated illegal operation faults within OS interruption handlers.
    The specific behavior is OS dependent.
    
    Implication: An application causing an illegal operation fault with
    specific RSE state may result in a series of illegal operation faults
    and an eventual OS stack overflow condition.
    
    Workaround: OS interruption handlers that switch to kernel backing
    store implement a check for invalid RSE state to avoid the series
    of illegal operation faults.
    
    The core of the workaround is the RSE_WORKAROUND code sequence
    inserted into each invocation of the SAVE_MIN_WITH_COVER and
    SAVE_MIN_WITH_COVER_R19 macros.  This sequence includes hard-coded
    constants that depend on the number of stacked physical registers
    being 96.  The rest of this patch consists of code to disable this
    workaround should this not be the case (with the presumption that
    if a future Itanium processor increases the number of registers, it
    would also remove the need for this patch).
    
    Move the start of the RBS up to a mod32 boundary to avoid some
    corner cases.
    
    The dispatch_illegal_op_fault code outgrew the spot it was
    squatting in when built with this patch and CONFIG_VIRT_CPU_ACCOUNTING=y
    Move it out to the end of the ivt.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>