linux-kernel - Re: [PATCH stable-3.0] ptrace: don't clear GROUP_STOP

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

Message-ID: <20111020144726.GB27610@redhat.com>
Date:	Thu, 20 Oct 2011 16:47:26 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	Greg KH <gregkh@...e.de>, Tejun Heo <htejun@...il.com>,
	Luke Macken <lmacken@...hat.com>, stable@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH stable-3.0] ptrace: don't clear GROUP_STOP_SIGMASK on
	double-stop

On 10/19, Greg KH wrote:
>
> On Mon, Sep 26, 2011 at 07:06:32PM +0200, Oleg Nesterov wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=740121
> >
> > 1. Luke Macken triggered WARN_ON(!(group_stop & GROUP_STOP_SIGMASK))
> >    in do_signal_stop().
> >
> >    This is because do_signal_stop() clears GROUP_STOP_SIGMASK part
> >    unconditionally but doesn't update it if task_is_stopped().
> >
> > 2. Looking at this problem I noticed that WARN_ON_ONCE(!ptrace) is
> >    not right, a stopped-but-resumed tracee can clone the untraced
> >    thread in the SIGNAL_STOP_STOPPED group, the new thread can start
> >    another group-stop.
> >
> >    Remove this warning, we need more fixes to make it true.
> >
> > Reported-by: Luke Macken <lmacken@...hat.com>
> > Signed-off-by: Oleg Nesterov <oleg@...hat.com>
>
> I still don't understand, did this fix ever get into Linus's tree?  If
> so, what is the git commit id.
>
> If not, why not?

I already explained:

	No. As I said, 3.1 has the similar problem. But not the same, and you
	need the quite different test-case to trigger the bug.

	We are discussing the possible fixes for 3.1, but this code was changed
	very much and it doesn't make sense to compare the fixes for 3.1 and 3.0.

IOW. This code was rewritten in 3.1, this particlular problem
was "fixed" by accident, but in fact the problem just mutated.

> I can't apply it to the 3.0-stable tree unless it is
> there, or there is a very good reason why it isn't.

OK, please ignore then.

Oleg.

--
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/