Messages in this thread | | | Date | Sat, 16 Mar 2013 19:41:28 +0000 | From | Al Viro <> | Subject | Re: vfs: lockdep splat with prepare_bprm_creds |
| |
On Fri, Mar 15, 2013 at 07:19:56PM +0100, Oleg Nesterov wrote: > On 03/15, Al Viro wrote: > > > > On Fri, Mar 15, 2013 at 12:07:14AM -0400, Sasha Levin wrote: > > > Hi all, > > > > > > While fuzzing with trinity inside a KVM tools guest running latest -next kernel > > > I've stumbled on the following. > > > > > > Dave Jones reported something similar, but that seemed to involve cgroup's mutex > > > and didn't seem like it was the same issue as this one. > > > > Lovely... It's an execve() attempt on a "binary" that is, in fact, a procfs > > file (/proc/<pid>/stack),
> Cough... I am shy to disclose my ignorance, but could you explain how > open_exec()->do_filp_open(MAY_EXEC) can succeed in this case? At least > acl_permission_check() looks as if open_exec() should fail...
Umm... point. It might be a false positive, actually - some other seq_file-based sucker (while chmod +x /proc/self/stack will fail, chmod +x /proc/vmstat won't) that could be fed to execve(), leading to 1) kernel_read() from execve() can grab m.lock for *some* seq_file m, while holding ->cred_guard_mutex 2) read() on /proc/self/stack tries to grab ->cred_guard_mutex, while holding m.lock for a different seq_file m ... with lockdep having no idea that there's a reason why (1) and (2) can't have the same seq_file involved, said reason being that all files with ->read() trying to grab ->cred_guard_mutex don't have exec bit set *and* are impossible to chmod.
| |