Bug 186895

Summary:	CVE-2006-1066 arch/x86_64/kernel/traps.c PTRACE_SINGLESTEP oops
Product:	Red Hat Enterprise Linux 4	Reporter:	Marcel Holtmann <holtmann>
Component:	kernel	Assignee:	Jim Paradis <jparadis>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron, peterm, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	impact=low,source=lkml,reported=20060227,public=20060227
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-06-22 22:36:07 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:

Description Marcel Holtmann 2006-03-27 09:16:06 UTC

We found a problem with x86_64 kernels with preemption enabled, where having
multiple tasks doing ptrace singlesteps around the same time will cause the
system to 'oops'. The problem seems that a task can get preempted out of the
do_debug() processing while it is running on the DEBUG_STACK stack. If another
task on that same cpu then enters do_debug() and uses the same per-cpu
DEBUG_STACK stack, the previous preempted tasks's stack contents can be
corrupted, and the system will oops when the preempted task is context switched
back in again.

http://marc.theaimsgroup.com/?l=linux-kernel&m=113932292516359&w=2

This affects Linux kernel 2.6.16-rc2 and earlier.

The CVE-2006-1066 speaks about an ia64 problem which seems wrong.

Comment 1 Dave Jones 2006-03-27 20:54:55 UTC

we only have a limited backport of voluntary preempt in rhel4, is that
sufficient to trigger this ?  The report reads more like this is CONFIG_PREEMPT
related only, which would make it a non-problem on RHEL4.

Comment 2 Marcel Holtmann 2006-05-11 14:02:53 UTC

I am not sure if this affects RHEL4 or not. Someone with deeper knowledge should
take a look at it and then fix it or close this bug.

Comment 3 Jim Paradis 2006-06-22 22:36:07 UTC

This definitely appears to be a bug only if CONFIG_PREEMPT is set, which it is
not on RHEL4.  On a stock RHEL4 kernel I ran the reproducer numerous times
without incident.  When I rebuilt the kernel with CONFIG_PREEMPT set it crashed
the first time.

Since this bug involves a feature we neither distribute nor support, I'm closing
as WONTFIX.