[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120215143606.GA14037@redhat.com>
Date: Wed, 15 Feb 2012 15:36:06 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Cyrill Gorcunov <gorcunov@...nvz.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Emelyanov <xemul@...allels.com>,
Andrey Vagin <avagin@...nvz.org>,
KOSAKI Motohiro <kosaki.motohiro@...il.com>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Glauber Costa <glommer@...allels.com>,
Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
Matt Helsley <matthltc@...ibm.com>,
Pekka Enberg <penberg@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Alexey Dobriyan <adobriyan@...il.com>, Valdis.Kletnieks@...edu,
Michal Marek <mmarek@...e.cz>,
Frederic Weisbecker <fweisbec@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: + syscalls-x86-add-__nr_kcmp-syscall-v8.patch added to -mm tree
> +/* The caller must have pinned the task */
> +static struct file *
> +get_file_raw_ptr(struct task_struct *task, unsigned int idx)
> +{
> + struct fdtable *fdt;
> + struct file *file;
> +
> + spin_lock(&task->files->file_lock);
task->files can be NULL, we can race with exit_files().
> + fdt = files_fdtable(task->files);
> + if (idx < fdt->max_fds)
> + file = fdt->fd[idx];
You can probably rely on rcu instead of ->file_lock, but this is minor.
> +SYSCALL_DEFINE5(kcmp, pid_t, pid1, pid_t, pid2, int, type,
> + unsigned long, idx1, unsigned long, idx2)
> +{
> + struct task_struct *task1, *task2;
> + int ret;
> +
> + rcu_read_lock();
> +
> + /*
> + * Tasks are looked up in caller's PID namespace only.
> + */
> + task1 = find_task_by_vpid(pid1);
> + task2 = find_task_by_vpid(pid2);
> + if (!task1 || !task2)
> + goto err_no_task;
> +
> + get_task_struct(task1);
> + get_task_struct(task2);
> +
> + rcu_read_unlock();
> +
> + /*
> + * One should have enough rights to inspect task details.
> + */
> + if (!ptrace_may_access(task1, PTRACE_MODE_READ) ||
> + !ptrace_may_access(task2, PTRACE_MODE_READ)) {
> + ret = -EACCES;
Well, probably this is fine... but may be you can add a comment.
The task can change its credentials right after ptrace_may_access()
succeeds. This _looks_ wrong, perhaps it makes sense to add the
"we do not care" note.
Oleg.
--
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/
Powered by blists - more mailing lists