linux-kernel - Re: [PATCH] fs/proc: smaps should avoid VM

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] [day] [month] [year] [list]

Date:	Mon, 29 Apr 2013 21:03:08 -0400
From:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To:	Cliff Wickman <cpw@....com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mgorman@...e.de, paul.mundt@...ia.com, dhowells@...hat.com,
	aarcange@...hat.com, hughd@...gle.com, gorcunov@...nvz.org,
	kamezawa.hiroyuki@...il.com, eag0628@...il.com,
	khlebnikov@...nvz.org, sasha.levin@...cle.com,
	siddhesh.poyarekar@...il.com, rientjes@...gle.com,
	kirill.shutemov@...ux.intel.com, viro@...IV.linux.org.uk,
	amwang@...hat.com
Subject: Re: [PATCH] fs/proc: smaps should avoid VM_PFNMAP areas

Hello Cliff,

On Mon, Apr 29, 2013 at 04:25:53PM -0500, Cliff Wickman wrote:
> 
> /proc/<pid>/smaps should not be looking at VM_PFNMAP areas.
> 
> Certain tests in show_smap() (especially for huge pages) assume that the
> mapped PFN's are backed with page structures.  And this is not usually true
> for VM_PFNMAP areas.  This can result in panics on kernel page faults when
> attempting to address those page structures.

I think it's strange that you mention to hugepages, because in my understanding
VM_PFNMAP and hugepage related vma (VM_HUGEPAGE or VM_HUGETLB) should not set
at the same time. In what testcase are these flags both set?

And I guess this race can also happen on reading pagemap or numa_maps because
walk_page_range() is called in those code paths. Are you sure the race doesn't
happen on these paths? If not, please add a few more flag checks for them.

Thanks,
Naoya Horiguchi

> VM_PFNMAP areas are used by
> - graphics memory manager   gpu/drm/drm_gem.c
> - global reference unit     sgi-gru/grufile.c
> - sgi special memory        char/mspec.c
> - probably several out-of-tree modules
> 
> I'm copying everyone who has changed fs/proc/task_mmu.c recently, in case
> of some reason to provide /proc/<pid>/smaps for these areas that I am not
> aware of.
> 
> Signed-off-by: Cliff Wickman <cpw@....com>
> ---
>  fs/proc/task_mmu.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -589,6 +589,9 @@ static int show_smap(struct seq_file *m,
>  		.private = &mss,
>  	};
>  
> +	if (vma->vm_flags & VM_PFNMAP)
> +		return 0;
> +
>  	memset(&mss, 0, sizeof mss);
>  	mss.vma = vma;
>  	/* mmap_sem is held in m_start */
> --
> 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/
--
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/