linux-kernel - [PATCH 4.17 034/336] mm: vmalloc: avoid racy handling of debugobjects in vunmap

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed,  1 Aug 2018 18:46:09 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Chintan Pandya <cpandya@...eaurora.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Byungchul Park <byungchul.park@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Laura Abbott <labbott@...hat.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Wei Yang <richard.weiyang@...il.com>,
        Yisheng Xie <xieyisheng1@...wei.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: [PATCH 4.17 034/336] mm: vmalloc: avoid racy handling of debugobjects in vunmap

4.17-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Chintan Pandya <cpandya@...eaurora.org>

[ Upstream commit f3c01d2f3ade6790db67f80fef60df84424f8964 ]

Currently, __vunmap flow is,
 1) Release the VM area
 2) Free the debug objects corresponding to that vm area.

This leave some race window open.
 1) Release the VM area
 1.5) Some other client gets the same vm area
 1.6) This client allocates new debug objects on the same
      vm area
 2) Free the debug objects corresponding to this vm area.

Here, we actually free 'other' client's debug objects.

Fix this by freeing the debug objects first and then releasing the VM
area.

Link: http://lkml.kernel.org/r/1523961828-9485-2-git-send-email-cpandya@codeaurora.org
Signed-off-by: Chintan Pandya <cpandya@...eaurora.org>
Reviewed-by: Andrew Morton <akpm@...ux-foundation.org>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Byungchul Park <byungchul.park@....com>
Cc: Catalin Marinas <catalin.marinas@....com>
Cc: Florian Fainelli <f.fainelli@...il.com>
Cc: Johannes Weiner <hannes@...xchg.org>
Cc: Laura Abbott <labbott@...hat.com>
Cc: Vlastimil Babka <vbabka@...e.cz>
Cc: Wei Yang <richard.weiyang@...il.com>
Cc: Yisheng Xie <xieyisheng1@...wei.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 mm/vmalloc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1519,7 +1519,7 @@ static void __vunmap(const void *addr, i
 			addr))
 		return;
 
-	area = remove_vm_area(addr);
+	area = find_vmap_area((unsigned long)addr)->vm;
 	if (unlikely(!area)) {
 		WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
 				addr);
@@ -1529,6 +1529,7 @@ static void __vunmap(const void *addr, i
 	debug_check_no_locks_freed(addr, get_vm_area_size(area));
 	debug_check_no_obj_freed(addr, get_vm_area_size(area));
 
+	remove_vm_area(addr);
 	if (deallocate_pages) {
 		int i;