linux-kernel - Re: [PATCH] do not abuse ->cred_guard_mutex in threadgroup

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: <20130321150626.a7934d989fb80d835fa92255@linux-foundation.org>
Date:	Thu, 21 Mar 2013 15:06:26 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	cgroups@...r.kernel.org, Li Zefan <lizefan@...wei.com>
Subject: Re: [PATCH] do not abuse ->cred_guard_mutex in threadgroup_lock()

On Thu, 21 Mar 2013 17:21:38 +0100 Oleg Nesterov <oleg@...hat.com> wrote:

> threadgroup_lock() takes signal->cred_guard_mutex to ensure that
> thread_group_leader() is stable. This doesn't look nice, the scope
> of this lock in do_execve() is huge.
> 
> And as Dave pointed out this can lead to deadlock, we have the
> following dependencies:
> 
> 	do_execve:		cred_guard_mutex -> i_mutex
> 	cgroup_mount:		i_mutex -> cgroup_mutex
> 	attach_task_by_pid:	cgroup_mutex -> cred_guard_mutex
> 
> Change de_thread() to take threadgroup_change_begin() around the
> switch-the-leader code and change threadgroup_lock() to avoid
> ->cred_guard_mutex.
> 
> Note that de_thread() can't sleep with ->group_rwsem held, this
> can obviously deadlock with the exiting leader if the writer is
> active, so it does threadgroup_change_end() before schedule().

<formletter>
When writing a changelog, please describe the end-user-visible effects
of the bug, so that others can more easily decide which kernel
version(s) should be fixed, and so that downstream kernel maintainers
can more easily work out whether this patch will fix a problem which
they or their customers are observing.
</formletter>

> Reported-by: Dave Jones <davej@...hat.com>

Perhaps Dave's report provides the needed info?  trinity went titsup?


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