linux-kernel - Re: Leaks in trace reported by kmemleak

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]

Date:	Fri, 16 Oct 2009 15:11:23 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Zdenek Kabelac <zdenek.kabelac@...il.com>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Leaks in trace reported by kmemleak

Zdenek Kabelac <zdenek.kabelac@...il.com> wrote:
> Yes -same - though I forget to mention that log contained these two
> extra messages:
> (got lost in other debug stuff :( )...
>
> So it could be the parameters in your first patch were not correct ?
>
> [drm] Initialized drm 1.1.0 20060810
> kmemleak: Scan area larger than object 0xffffffffa033b000

Ah, I forgot that kmemleak_scan_area takes an offset inside an object
rather than an absolute address. Something like below (I should
actually change this prototype of this function, it doesn't need to be
so complex):

diff --git a/kernel/module.c b/kernel/module.c
index 8b7d880..8cc4406 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2383,6 +2383,10 @@ static noinline struct module *load_module(void __user *umod,
 					 "_ftrace_events",
 					 sizeof(*mod->trace_events),
 					 &mod->num_trace_events);
+	kmemleak_scan_area(mod->module_core, (unsigned long)mod->trace_events -
+			   (unsigned long)mod->module_core,
+			   sizeof(*mod->trace_events) * mod->num_trace_events,
+			   GFP_KERNEL);
 #endif
 #ifdef CONFIG_FTRACE_MCOUNT_RECORD
 	/* sechdrs[0].sh_size is always zero */

> BTW - it's kind of ugly - that module removal destroys stack trace -
> it would be nice to see some hook for module unload - to eventually
> create a permanent stack trace for this occasion??

Kmemleak only uses whatever stacktrace mechanism is available in the
kernel. Resolving the symbol names when objects are allocated would
slow it down and it takes up more space in the traces. I don't have a
proper solution.

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