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]
Message-ID: <571C410F.6020601@linux.vnet.ibm.com>
Date:	Sun, 24 Apr 2016 11:44:15 +0800
From:	Yongji Xie <xyjxie@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
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 2016/4/23 2:38, Andrew Morton wrote:
> 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?

No, this is just a fix in theory:-) .

>> --- 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?
>

Yes, it's a little difficult to understand this. I will send a v2 soon.

Thanks,
Yongji

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ