linux-kernel - Re: [PATCH] proc: fix pagemap_read() error case (was Re: [PATCH] proc: put check_mem_permission before __get_free_page in mem

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: <alpine.LSU.2.00.1104261321550.9533@sister.anvils>
Date:	Tue, 26 Apr 2011 13:44:10 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc:	bookjovi@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	David Rientjes <rientjes@...gle.com>,
	Stephen Wilson <wilsons@...rt.ca>,
	open list <linux-kernel@...r.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)

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@...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@...fujitsu.com>
> Cc: Hugh Dickins <hughd@...gle.com>

Acked-by: Hugh Dickins <hughd@...gle.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
--
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/