All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Christopher Yeoh <cyeoh@au1.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] Fix race in process_vm_rw_core
Date: Fri, 13 Jan 2012 17:04:42 +0100	[thread overview]
Message-ID: <20120113160442.GA20137@redhat.com> (raw)
In-Reply-To: <20120113220028.4ba7cead@Gantu.yeoh.info>

On 01/13, Christopher Yeoh wrote:
>
> Hi Linus,
>
> Below is a patch which fixes the race in process_vm_core found by
> Oleg (http://article.gmane.org/gmane.linux.kernel/1235667/).
> It consolidates some code with mm_for_maps since what they do is almost
> identical.
>
> Oleg - I've kept the breakout of ptrace_may_attach and get_task_mm to
> preserve only having to take the task lock once. I see some performance
> difference with a microbenchmark but haven't had a chance to test with
> some HPC benchmarks yet so for the moment I'd like to leave it in.

I still think we should avoid the copy-and-paste code, we can do this
without the extra unlock+lock if it hurts.

However,

> At
> this stage I think its more important to get the race fixed and I'm at
> Linux.conf.au all next week. I'll send a patch out for the
> rw_copy_check_uvector cleanup after I get back from LCA.

OK, lets fix the bug first.

>  struct mm_struct *mm_for_maps(struct task_struct *task)
>  {
> -	struct mm_struct *mm;
> -	int err;
> -
> -	err =  mutex_lock_killable(&task->signal->cred_guard_mutex);
> -	if (err)
> -		return ERR_PTR(err);
> -
> -	mm = get_task_mm(task);
> -	if (mm && mm != current->mm &&
> -			!ptrace_may_access(task, PTRACE_MODE_READ)) {
> -		mmput(mm);
> -		mm = ERR_PTR(-EACCES);
> -	}
> -	mutex_unlock(&task->signal->cred_guard_mutex);
> -
> -	return mm;
> +	return get_check_task_mm(task, PTRACE_MODE_READ);
>  }
> ...
> +struct mm_struct *get_check_task_mm(struct task_struct *task, unsigned int mode)
> +{
> +	struct mm_struct *mm;
> +	int err;
> +
> +	err =  mutex_lock_killable(&task->signal->cred_guard_mutex);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	task_lock(task);
> +	if (__ptrace_may_access(task, mode)) {
> +		mm = ERR_PTR(-EACCES);
> +		goto out;
> +	}

Probably you should check "mm != current->mm" before __ptrace_may_access(),
otherwise this changes the rules for, say, /proc/pid/maps.

> @@ -298,23 +298,15 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec,
>  		goto free_proc_pages;
>  	}
>
> -	task_lock(task);
> -	if (__ptrace_may_access(task, PTRACE_MODE_ATTACH)) {
> -		task_unlock(task);
> -		rc = -EPERM;
> -		goto put_task_struct;
> -	}
> -	mm = task->mm;
> -
> -	if (!mm || (task->flags & PF_KTHREAD)) {
> -		task_unlock(task);
> -		rc = -EINVAL;
> +	mm = get_check_task_mm(task, PTRACE_MODE_ATTACH);
> +	if (!mm || IS_ERR(mm)) {
> +		if (!mm)
> +			rc = -EINVAL;
> +		else
> +			rc = -EPERM;

Cosmetic nit. I won't insist, but why -EPERM is better than -EACCES
returned by get_check_task_mm()? IOW, why not rc = PTR_ERR() ?

Note that get_check_task_mm() can return -EINTR, in this case -EPERM
looks confusing even if this doesn't really materr (the killed task
can't return to usermode).

Oleg.


  reply	other threads:[~2012-01-13 16:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 11:30 [PATCH] Fix race in process_vm_rw_core Christopher Yeoh
2012-01-13 16:04 ` Oleg Nesterov [this message]
2012-01-13 23:26   ` Christopher Yeoh
2012-01-14 17:58     ` Oleg Nesterov
2012-01-16  2:56       ` Christopher Yeoh
2012-01-16 18:59         ` Oleg Nesterov
2012-01-13 22:30 ` Andrew Morton
2012-01-13 23:30   ` Christopher Yeoh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120113160442.GA20137@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cyeoh@au1.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.