linux-kernel - Re: splice vs execve lockdep trace.

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: <20130716023847.GA31481@redhat.com>
Date:	Mon, 15 Jul 2013 22:38:48 -0400
From:	Dave Jones <davej@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Oleg Nesterov <oleg@...hat.com>, Ben Myers <bpm@....com>
Subject: Re: splice vs execve lockdep trace.

On Mon, Jul 15, 2013 at 07:32:51PM -0700, Linus Torvalds wrote:

 > So the problematic op *seems* to be the splice into /proc/<pid>/attr/
 > files, which causes that "pipe -> cred_guard_mutex" locking.
 > 
 > While the *normal* ordering would be the other way around, coming from
 > execve(), which has the cred_guard_mutex -> VFS locks ordering for
 > reading the executable headers.
 > 
 > Al, can we break either of those? Do we need to hold on to the cred
 > mutex that long? We get it fairly early (prepare_bprm_creds) and we
 > drop it very late (install_exec_creds), which means that it covers a
 > lot. But that seems pretty basic. The splice into /proc/<pid>/attr/*
 > seems to be the more annoying one, and maybe we just shouldn't allow
 > splicing into or from /proc?
 > 
 > Dave, is this new (it doesn't *smell* new to me), or is it just that
 > trinity is doing new splice things?
 
I think I've seen this a long time ago from another fuzzer (iknowthis).
I thought that had gotten fixed though.  But I may be mixing up a
similar callchain.  The recent trinity changes shouldn't have really made
any notable difference here.  Interestingly, the 'soft lockups' I was
seeing all the time on that box seem to have gone into hiding.

 > Or is the XFS i_iolock required for this thing to happen at all?
 > Adding Ben Myers to the cc just for luck/completeness.

It is only happening (so far) on the XFS test box, but I don't have
enough data to say that's definite yet.
 
	Dave
 
--
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/