linux-kernel - Re: [PATCH] do_task_stat: don't use task_pid_nr

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: <m1zlxaun5k.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 19 Nov 2007 11:04:55 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	Oleg Nesterov <oleg@...sign.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] do_task_stat: don't use task_pid_nr_ns() lockless

Pavel Emelyanov <xemul@...nvz.org> writes:

> Eric W. Biederman wrote:
>> We only get detached in release_task so it is a pretty small window
>> where we can return pid == 0.  Usually get_task_pid will fail first
>> and we will return -ESRCH.  Still the distance from open to 
>> 
>> There is another bug in here as well.  current->nsproxy->pid_ns is wrong.
>> What we want is: ns = dentry->d_sb->s_fs_info;
>
> Actually I thought about this recently - if we produce the list
> of tasks based on the sb's namespace, then we should fill the
> tasks' files according to the sb's namespace as well, not according
> to the current namespace.

Exactly.  That is the problem I was pointing out.  Patch in a bit.
In do_proc_stat we are currently referencing current->nsproxy->pid_ns;

>> Otherwise we will have file descriptor passing races and the like.
>
> Can you elaborate?

Just the classic problem that if you use current at other then open
time the contents of the file descriptor may depend on who is reading
it which is problematic.

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