>Number:         26804
>Category:       kern
>Synopsis:       PT_COREDUMP is totally horked
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 29 22:34:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Jason R Thorpe
>Release:        NetBSD 2.0G
>Organization:
        -- Jason R. Thorpe <thorpej@shagadelic.org>
>Environment:
	
	
System: NetBSD yeah-baby.shagadelic.org 2.0G NetBSD 2.0G (YEAH-BABY-XP) #26: Thu Jul 15 08:26:49 PDT 2004 thorpej@yeah-baby.shagadelic.org:/u1/netbsd/src/sys/arch/i386/compile/YEAH-BABY-XP i386
Architecture: i386
Machine: i386
>Description:
	PT_COREDUMP is implemented in the most naive way possible,
	and gets it totally wrong as a result.

	The root of all of its problems revolves around the fact that
	the target processes isn't actually suspended before the core
	dump is taken.  This means that the process can modify its
	address space / VM map while the core dump is being performed,
	risking an inconsistent dump or a kernel panic.

	Observe how PT_DUMPCORE does not require P_TRACED to be set.

>How-To-Repeat:
	Code observation.

>Fix:
	Not provided.  A good first step might be to require PT_DUMPCORE
	to require the target process to be PT_ATTACHED.
>Release-Note:
>Audit-Trail:
>Unformatted: