Bug 470954 - [REG] kernel-xen 3.1.1 does not prevent modification of the CR4 TSC from applications (DoS possible)
Summary: [REG] kernel-xen 3.1.1 does not prevent modification of the CR4 TSC from appl...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: CVE-2007-5907 470955 470956
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-11 03:27 UTC by Eugene Teo (Security Response)
Modified: 2009-02-18 09:07 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-18 09:07:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Eugene Teo (Security Response) 2008-11-11 03:27:01 UTC
+++ This bug was initially created as a clone of Bug #377561 +++

Description of problem:

Xen 3.1.1 does not prevent modification of the CR4 TSC from
applications, which allows pv guests to cause a denial of service
(crash). (CVE-2007-5907).

--- Additional comment from jlieskov on 2007-11-16 09:59:27 EDT ---

The official post is here -- there is also patch provided: 
 
http://lists.xensource.com/archives/html/xen-devel/2007-10/msg00932.html 

--- Additional comment from eteo on 2008-08-10 21:28:06 EDT ---

Proposed patch for then rhel-5.2
http://post-office.corp.redhat.com/archives/rhkernel-list/2008-March/msg01393.html

--- Additional comment from clalance on 2008-09-12 10:13:05 EDT ---

Created an attachment (id=316578)
Patch to allow guest kernels to trap CR4 access

This is the current patch I've been testing for this issue.  It's pretty close to xen-unstable c/s 16259 + 16333, but has the following modifications:

1)  irq_masked() is called in a few different places in the 3.1 codebase, so fix up all of the callers of it.
2)  Remove all calls to pge_off and pge_on.  Upstream went with a re-written flushing mechanism before this c/s went in, so just make sure to follow the pge_off/pge_on discipline that was there.

Chris Lalancette

--- Additional comment from clalance on 2008-09-16 05:46:59 EDT ---

(From update of attachment 316578 [details])
Since this is the master tracking bug, this patch doesn't belong here.  Obsoleting.

Comment 1 Eugene Teo (Security Response) 2008-11-11 03:29:00 UTC
The fix for this has caused regressions in some systems. This bug is used to keep track of the regression to ensure that we resolve this ASAP.

Comment 3 Eugene Teo (Security Response) 2008-11-11 03:46:24 UTC
(In reply to comment #1)
> The fix for this has caused regressions in some systems. This bug is used to
> keep track of the regression to ensure that we resolve this ASAP.

*this* refers to CVE-2007-5907. Thanks.

Comment 4 Eugene Teo (Security Response) 2008-11-11 08:27:16 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > The fix for this has caused regressions in some systems. This bug is used to
> > keep track of the regression to ensure that we resolve this ASAP.
> 
> *this* refers to CVE-2007-5907. Thanks.

Just to clarify. The fix for CVE-2007-5907 did not introduce a new security vulnerability. It introduced a normal bug where the kernel does not boot on certain hardware. I have removed the assigned CVE name, and Security keyword from the bugs. Thanks.

Comment 5 Chris Lalancette 2009-01-22 08:28:21 UTC
The CVE and the regression caused by the initial patch has been solved in both the 5.2.z stream and 5.3.  I'm not quite sure of the procedure with security bugs, but can we close this out now?

Chris Lalancette

Comment 6 Eugene Teo (Security Response) 2009-02-18 07:33:46 UTC
Yes. Please close the bug, thanks.

Comment 7 Chris Lalancette 2009-02-18 09:07:03 UTC
Great, thanks.  Closing.


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