Bug 470954

Summary:	[REG] kernel-xen 3.1.1 does not prevent modification of the CR4 TSC from applications (DoS possible)
Product:	[Other] Security Response	Reporter:	Eugene Teo (Security Response) <eteo>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	anton, bburns, clalance, dhoward, dzickus, jpirko, kernel-maint, kreilly, lwang, xen-maint
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-18 09:07:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	377561, 470955, 470956
Bug Blocks:

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.