Re: vfs: lockdep splat with prepare_bprm_creds
On 03/16, Al Viro wrote:
>
> On Fri, Mar 15, 2013 at 07:19:56PM +0100, Oleg Nesterov wrote:
>
> > 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
Yes, thanks.
I am wondering if lock_trace() is really useful...
Lets ignore proc_pid_syscall() and proc_pid_personality(). Suppose we
change proc_pid_stack()
int proc_pid_stack(...)
{
...
save_stack_trace_tsk(task, &trace);
if (!ptrace_may_access(task, PTRACE_MODE_ATTACH))
goto return -EPERM;
for (i = 0; i < trace.nr_entries; i++)
seq_printf(...);
return 0;
}
Sure, without cred_guard_mutex we can race with install_exec_creds(). But
is it a problem in practice? In any case lock_trace() can't protect against
commit_creds()...
We can even do
task_lock(task);
err = __ptrace_may_access(task, mode);
if (!err)
save_stack_trace_tsk(...);
task_unlock(task);
This way task_lock() protects us against exec_mmap(). And even exec_mmap()
was already called and the task is going to do install_exec_creds() we can't
show the stack of this process "after" exec.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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//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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vfs: lockdep splat with prepare_bprm_creds
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//stack),
probably... other lock_trace() callers can't generate this lockdep output
afaics.
> with its ->read() trying to grab ->cred_guard_mutex.
> The fact that it's seq_file-based is irrelevant here - all that matters is
> that we have ->read() for some file trying to grab ->cred_guard_mutex.
Yes, perhaps the patch below makes sense anyway as a cleanup, but obviously
it can't help.
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...
Just curious, thanks in advance.
Oleg.
--- x/fs/proc/base.c
+++ x/fs/proc/base.c
@@ -317,12 +317,12 @@ static int proc_pid_stack(struct seq_fil
err = lock_trace(task);
if (!err) {
save_stack_trace_tsk(task, &trace);
+ unlock_trace(task);
for (i = 0; i < trace.nr_entries; i++) {
seq_printf(m, "[<%pK>] %pS\n",
(void *)entries[i], (void *)entries[i]);
}
- unlock_trace(task);
}
kfree(entries);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vfs: lockdep splat with prepare_bprm_creds
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//stack), with its ->read() trying to grab ->cred_guard_mutex. The fact that it's seq_file-based is irrelevant here - all that matters is that we have ->read() for some file trying to grab ->cred_guard_mutex. It's not *quite* a deadlock, though - all these guys are using mutex_lock_killable()... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
