Bug 186895 - CVE-2006-1066 arch/x86_64/kernel/traps.c PTRACE_SINGLESTEP oops
CVE-2006-1066 arch/x86_64/kernel/traps.c PTRACE_SINGLESTEP oops
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jim Paradis
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2006-03-27 04:16 EST by Marcel Holtmann
Modified: 2013-08-05 21:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-22 18:36:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marcel Holtmann 2006-03-27 04:16:06 EST
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.


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 15:54:55 EST
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 10:02:53 EDT
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 18:36:07 EDT
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

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