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
| ||
|
Message-Id: <e8d4c0b2-dfb5-8d4d-3bcc-30b8915d24cb@linux.vnet.ibm.com> Date: Tue, 17 Apr 2018 08:39:36 +0530 From: Anshuman Khandual <khandual@...ux.vnet.ibm.com> To: Chintan Pandya <cpandya@...eaurora.org>, Anshuman Khandual <khandual@...ux.vnet.ibm.com>, vbabka@...e.cz, labbott@...hat.com, catalin.marinas@....com, hannes@...xchg.org, f.fainelli@...il.com, xieyisheng1@...wei.com, ard.biesheuvel@...aro.org, richard.weiyang@...il.com, byungchul.park@....com Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 2/2] mm: vmalloc: Pass proper vm_start into debugobjects On 04/16/2018 05:39 PM, Chintan Pandya wrote: > > > On 4/13/2018 5:31 PM, Anshuman Khandual wrote: >> On 04/13/2018 05:03 PM, Chintan Pandya wrote: >>> Client can call vunmap with some intermediate 'addr' >>> which may not be the start of the VM area. Entire >>> unmap code works with vm->vm_start which is proper >>> but debug object API is called with 'addr'. This >>> could be a problem within debug objects. >>> >>> Pass proper start address into debug object API. >>> >>> Signed-off-by: Chintan Pandya <cpandya@...eaurora.org> >>> --- >>> mm/vmalloc.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >>> index 9ff21a1..28034c55 100644 >>> --- a/mm/vmalloc.c >>> +++ b/mm/vmalloc.c >>> @@ -1526,8 +1526,8 @@ static void __vunmap(const void *addr, int >>> deallocate_pages) >>> return; >>> } >>> - debug_check_no_locks_freed(addr, get_vm_area_size(area)); >>> - debug_check_no_obj_freed(addr, get_vm_area_size(area)); >>> + debug_check_no_locks_freed(area->addr, get_vm_area_size(area)); >>> + debug_check_no_obj_freed(area->addr, get_vm_area_size(area)); >> >> This kind of makes sense to me but I am not sure. We also have another >> instance of this inside the function vm_unmap_ram() where we call for > Right, I missed it. I plan to add below stub in v2. > > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1124,15 +1124,15 @@ void vm_unmap_ram(const void *mem, unsigned int > count) > BUG_ON(addr > VMALLOC_END); > BUG_ON(!PAGE_ALIGNED(addr)); > > - debug_check_no_locks_freed(mem, size); > - > if (likely(count <= VMAP_MAX_ALLOC)) { > + debug_check_no_locks_freed(mem, size); It should have been 'va->va_start' instead of 'mem' in here but as said before it looks correct to me but I am not really sure.
Powered by blists - more mailing lists