mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: bookjovi@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	David Rientjes <rientjes@google.com>,
	Stephen Wilson <wilsons@start.ca>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] proc: fix pagemap_read() error case (was Re: [PATCH] proc: put check_mem_permission before __get_free_page in mem_read)
Date: Tue, 26 Apr 2011 13:44:10 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LSU.2.00.1104261321550.9533@sister.anvils> (raw)
In-Reply-To: <20110426145226.F383.A69D9226@jp.fujitsu.com>

On Tue, 25 Apr 2011, KOSAKI Motohiro wrote:
> 
> I've finished audit other /proc allocation callsite. If my understand
> is correct, only pagemap_read() has the same issue.
> 
> fixed.

Great, thank you.  Though I see Steve has cleverly spotted another:
yes, that should be worth looking into, but I've not studied it.

I confess that when I wrote yesterday, I thought there were a lot more
such instances in fs/proc.  I thought /proc/pid/smaps was vulnerable,
for example, but I cannot see that now: maybe I just confused it with
/proc/pid/pagemap.

I was worrying about this a couple of months ago, when David had an
OOM dump with OOM-killed threads failing to exit because they could
not skb_alloc in proc_exit_connector()'s cn_netlink_send() - connector
needs to allocate skb upfront (I'm being vague!), not when thread exits.

But it was a mystery why memory was still unavailable at that late
stage: my unsubstantiated suspicion was that something else was
holding on to the mm-to-be-freed while trying to allocate memory.

> 
> 
> From 5f83db14a7c62381c4f23994d559041c4c3320a8 Mon Sep 17 00:00:00 2001
> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Date: Tue, 26 Apr 2011 14:26:52 +0900
> Subject: [PATCH] proc: fix pagemap_read() error case
> 
> Currently, pagemap_read() has three error and/or corner case
> handling mistake.
>  (1) If ppos parameter is wrong, mm refcount will be leak.
>  (2) If count parameter is 0, mm refcount will be leak too.
>  (3) If the current task is sleeping in kmalloc() and the system
>      is out of memory and oom-killer kill the proc associated task,
>      mm_refcount prevent the task free its memory. then system may
>      hang up.
> 
> <Quote Hugh's explain why we shold call kmalloc() before get_mm()>
>   check_mem_permission gets a reference to the mm.  If we __get_free_page
>   after check_mem_permission, imagine what happens if the system is out
>   of memory, and the mm we're looking at is selected for killing by the
>   OOM killer: while we wait in __get_free_page for more memory, no memory
>   is freed from the selected mm because it cannot reach exit_mmap while
>   we hold that reference.
> 
> This patch fixes the above three.
> 
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Hugh Dickins <hughd@google.com>

Acked-by: Hugh Dickins <hughd@google.com>

> ---
>  fs/proc/task_mmu.c |   19 +++++++++----------
>  1 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 51b9d98..6fb07ce 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -769,18 +769,12 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
>  	if (!task)
>  		goto out;
>  
> -	mm = mm_for_maps(task);
> -	ret = PTR_ERR(mm);
> -	if (!mm || IS_ERR(mm))
> -		goto out_task;
> -
>  	ret = -EINVAL;
>  	/* file position must be aligned */
>  	if ((*ppos % PM_ENTRY_BYTES) || (count % PM_ENTRY_BYTES))
>  		goto out_task;
>  
>  	ret = 0;
> -
>  	if (!count)
>  		goto out_task;
>  
> @@ -788,7 +782,12 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
>  	pm.buffer = kmalloc(pm.len, GFP_TEMPORARY);
>  	ret = -ENOMEM;
>  	if (!pm.buffer)
> -		goto out_mm;
> +		goto out_task;
> +
> +	mm = mm_for_maps(task);
> +	ret = PTR_ERR(mm);
> +	if (!mm || IS_ERR(mm))
> +		goto out_free;
>  
>  	pagemap_walk.pmd_entry = pagemap_pte_range;
>  	pagemap_walk.pte_hole = pagemap_pte_hole;
> @@ -831,7 +830,7 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
>  		len = min(count, PM_ENTRY_BYTES * pm.pos);
>  		if (copy_to_user(buf, pm.buffer, len)) {
>  			ret = -EFAULT;
> -			goto out_free;
> +			goto out_mm;
>  		}
>  		copied += len;
>  		buf += len;
> @@ -841,10 +840,10 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
>  	if (!ret || ret == PM_END_OF_BUFFER)
>  		ret = copied;
>  
> -out_free:
> -	kfree(pm.buffer);
>  out_mm:
>  	mmput(mm);
> +out_free:
> +	kfree(pm.buffer);
>  out_task:
>  	put_task_struct(task);
>  out:
> -- 
> 1.7.3.1

  parent reply	other threads:[~2011-04-26 20:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-18  0:20 [PATCH] proc: put check_mem_permission before __get_free_page in mem_read bookjovi
2011-04-24 15:33 ` KOSAKI Motohiro
2011-04-25 14:31 ` Stephen Wilson
2011-04-26  3:56 ` Hugh Dickins
2011-04-26  5:12   ` KOSAKI Motohiro
2011-04-26  5:50     ` [PATCH] proc: fix pagemap_read() error case (was Re: [PATCH] proc: put check_mem_permission before __get_free_page in mem_read) KOSAKI Motohiro
2011-04-26 16:44       ` Stephen Wilson
2011-04-26 20:44       ` Hugh Dickins [this message]
2011-04-28  1:45         ` KOSAKI Motohiro
2011-04-26 16:03     ` [PATCH] proc: put check_mem_permission before __get_free_page in mem_read Stephen Wilson
2011-04-26 20:19     ` Hugh Dickins
2011-04-26  8:55   ` Jovi Zhang

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=alpine.LSU.2.00.1104261321550.9533@sister.anvils \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bookjovi@gmail.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wilsons@start.ca \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®