linux-kernel - Re: ptrace bugs and related problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 28 Jul 2006 16:07:56 -0400
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	Daniel Jacobowitz <dan@...ian.org>
Cc:	Albert Cahalan <acahalan@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: ptrace bugs and related problems

In-Reply-To: <20060728034741.GA3372@...yn.them.org>

(cc: trimmed)

On Thu, 27 Jul 2006 23:47:41 -0400, Daniel Jacobowitz wrote:
> 
> > In do_fork, the result of fork_traceflag is assigned
> > to the "trace" variable. Note that PT_TRACE_VFORK_DONE
> > does not cause "trace" to be non-zero.
> > 
> > Then we hit this code:
> > 
> >                if (unlikely (trace)) {
> >                        current->ptrace_message = nr;
> >                        ptrace_notify ((trace << 8) | SIGTRAP);
> >                }
> > 
> > That doesn't run. The ptrace_message is thus not set when
> > ptrace_notify is called to send the PTRACE_EVENT_VFORK_DONE
> > message. You get random stale data from a previous message.
> 
> Why do you want the message data anyway?
> 
> FORK/VFORK/CLONE events have a message: it says what the new process's
> PID is.  VFORK_DONE doesn't have a message, because it only indicates
> that the current process is about to resume; it's an event that only
> has one process associated with it.
> 
> I really don't think this is a bug.

Maybe not a bug, but this would be a nice enhancement.  It would cost
exactly one line of code.  I looked at user code I had written and it
assumed the message was available (it was, because I was also tracing
EVENT_VFORK and it happens to be left over from that.)  If we make this
a part of the API, future kernel changes wouldn't break this (erroneous)
assumption, which otherwise might give someone a nasty surprise in
currently-working code.

Otherwise we should zero it out and see what breaks. :)

-- 
Chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/