linux-kernel - Re: [PATCH 1/3] ptrace_detach: the wrong wakeup breaks the ERESTARTxxx logic

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090209013455.CB996FC330@magilla.sf.frob.com>
Date:	Sun,  8 Feb 2009 17:34:55 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jerome Marchand <jmarchan@...hat.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ptrace_detach: the wrong wakeup breaks the ERESTARTxxx
	logic

> This is because ptrace_detach does:
> 
> 	if (!child->exit_state)
> 		wake_up_process(child);

I'm pretty sure that all these uses of wake_up_process were just blindly
copied from an original use in ptrace code (what's now ptrace_resume).
That original use just dates from the beforetime, the long long ago.
(I don't think it indicates any coherent original intent.)

It's many kinds of wrong.  It's also always been wrong in case of a
simultaneous SIGKILL that already woke the child, which has then blocked on
some mutex or semaphore or whatnot.  I don't know what the stated general
policy about spurious wakeups from schedule() is supposed to be.  Perhaps
to be pedantic, the sys_pause() code has been wrong to return without
checking signal_pending().

It's also about as wrong to use blind wake_up_process in ptrace_resume.
It ought to be wake_up_state(__TASK_TRACED|__TASK_STOPPED).

Frankly, I've always been afraid of strange cruft that might unexpectedly
turn out to rely on this "wrong" (unconditional) wake-up.  Probably the
things like that historically were all just to do with the stopped/traced
bookkeeping and would be covered by explicitly dealing with PTRACE_CONT vs
group stop et al.  But FWIW my reaction to fiddling the wake_up_process
bogons in the past has been, "Be afraid."

Thanks,
Roland
--
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/