Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1272030 > unrolled thread

[PATCH v2] kasan: fix kmemleak false-positive in kasan_module_alloc()

Back to article view | Back to linux.kernel

Contents

  [PATCH v2] kasan: fix kmemleak false-positive in kasan_module_alloc() Andrey Ryabinin <aryabinin@virtuozzo.com> - 2015-11-18 10:30 +0100
    Re: [PATCH v2] kasan: fix kmemleak false-positive in kasan_module_alloc() Catalin Marinas <catalin.marinas@arm.com> - 2015-11-18 11:30 +0100

#1272030 — [PATCH v2] kasan: fix kmemleak false-positive in kasan_module_alloc()

Kmemleak reports the following leak:
	unreferenced object 0xfffffbfff41ea000 (size 20480):
	comm "modprobe", pid 65199, jiffies 4298875551 (age 542.568s)
	hex dump (first 32 bytes):
	  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
	  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
	backtrace:
	  [<ffffffff82354f5e>] kmemleak_alloc+0x4e/0xc0
	  [<ffffffff8152e718>] __vmalloc_node_range+0x4b8/0x740
	  [<ffffffff81574072>] kasan_module_alloc+0x72/0xc0
	  [<ffffffff810efe68>] module_alloc+0x78/0xb0
	  [<ffffffff812f6a24>] module_alloc_update_bounds+0x14/0x70
	  [<ffffffff812f8184>] layout_and_allocate+0x16f4/0x3c90
	  [<ffffffff812faa1f>] load_module+0x2ff/0x6690
	  [<ffffffff813010b6>] SyS_finit_module+0x136/0x170
	  [<ffffffff8239bbc9>] system_call_fastpath+0x16/0x1b
	  [<ffffffffffffffff>] 0xffffffffffffffff

kasan_module_alloc() allocates shadow memory for module and frees it on
module unloading. It doesn't store the pointer to allocated shadow memory
because it could be calculated from the shadowed address, i.e. kasan_mem_to_shadow(addr).
Since kmemleak cannot find pointer to allocated shadow, it thinks that
memory leaked.

Use kmemleak_ignore() to tell kmemleak that this is not a leak and shadow
memory doesn't contain any pointers.

Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
Changes since V1:
 - kmemleak_ingore() instead of kmemleak_not_leak() per Catalin

 mm/kasan/kasan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index d41b21b..bc0a8d8 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -19,6 +19,7 @@
 #include <linux/export.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/kmemleak.h>
 #include <linux/memblock.h>
 #include <linux/memory.h>
 #include <linux/mm.h>
@@ -444,6 +445,7 @@ int kasan_module_alloc(void *addr, size_t size)
 
 	if (ret) {
 		find_vm_area(addr)->flags |= VM_KASAN;
+		kmemleak_ignore(ret);
 		return 0;
 	}
 
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1272081

On 18 November 2015 at 09:26, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
> Kmemleak reports the following leak:
>         unreferenced object 0xfffffbfff41ea000 (size 20480):
>         comm "modprobe", pid 65199, jiffies 4298875551 (age 542.568s)
>         hex dump (first 32 bytes):
>           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>         backtrace:
>           [<ffffffff82354f5e>] kmemleak_alloc+0x4e/0xc0
>           [<ffffffff8152e718>] __vmalloc_node_range+0x4b8/0x740
>           [<ffffffff81574072>] kasan_module_alloc+0x72/0xc0
>           [<ffffffff810efe68>] module_alloc+0x78/0xb0
>           [<ffffffff812f6a24>] module_alloc_update_bounds+0x14/0x70
>           [<ffffffff812f8184>] layout_and_allocate+0x16f4/0x3c90
>           [<ffffffff812faa1f>] load_module+0x2ff/0x6690
>           [<ffffffff813010b6>] SyS_finit_module+0x136/0x170
>           [<ffffffff8239bbc9>] system_call_fastpath+0x16/0x1b
>           [<ffffffffffffffff>] 0xffffffffffffffff
>
> kasan_module_alloc() allocates shadow memory for module and frees it on
> module unloading. It doesn't store the pointer to allocated shadow memory
> because it could be calculated from the shadowed address, i.e. kasan_mem_to_shadow(addr).
> Since kmemleak cannot find pointer to allocated shadow, it thinks that
> memory leaked.
>
> Use kmemleak_ignore() to tell kmemleak that this is not a leak and shadow
> memory doesn't contain any pointers.
>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web