linux-kernel - Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in remap_pfn

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: <20160422113831.6294e65dbc4fe7a2d3421539@linux-foundation.org>
Date:	Fri, 22 Apr 2016 11:38:31 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Yongji Xie <xyjxie@...ux.vnet.ibm.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	kirill.shutemov@...ux.intel.com, jmarchan@...hat.com,
	mingo@...nel.org, vbabka@...e.cz, dave.hansen@...ux.intel.com,
	dan.j.williams@...el.com, matthew.r.wilcox@...el.com,
	aarcange@...hat.com, mhocko@...e.com, luto@...nel.org,
	dahi@...ux.vnet.ibm.com
Subject: Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in
 remap_pfn_range

On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie <xyjxie@...ux.vnet.ibm.com> wrote:

> We used generic hooks in remap_pfn_range to help archs to
> track pfnmap regions. The code is something like:
> 
> int remap_pfn_range()
> {
> 	...
> 	track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
> 	...
> 	pfn -= addr >> PAGE_SHIFT;
> 	...
> 	untrack_pfn(vma, pfn, PAGE_ALIGN(size));
> 	...
> }
> 
> Here we can easily find the pfn is changed but not recovered
> before untrack_pfn() is called. That's incorrect.

What are the runtime effects of this bug?

> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1755,6 +1755,7 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
>  			break;
>  	} while (pgd++, addr = next, addr != end);
>  
> +	pfn += (end - PAGE_ALIGN(size)) >> PAGE_SHIFT;
>  	if (err)
>  		untrack_pfn(vma, pfn, PAGE_ALIGN(size));

I'm having trouble understanding this.  Wouldn't it be better to simply
save the track_pfn_remap() call's `pfn' arg in a new local variable?