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]

Message-Id: <1255605778.10164.49.camel@pc1117.cambridge.arm.com>
Date:	Thu, 15 Oct 2009 12:22:58 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Zdenek Kabelac <zdenek.kabelac@...il.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

On Thu, 2009-10-15 at 17:46 +0800, Li Zefan wrote:
> Zdenek Kabelac wrote:
> > I've noticed your latest patch for memory leak in filter setting
> > (8ad807318fcd...) - but even with this patch - kmemleak seems to still
> > report  lots  (~900) of following leaks - note - they come only from
> > i915 and kvm module - so I'm not sure if these two modules are doing
> > something wrong or the problem is in trace code.
> > 
> > It looks like whole directory is somehow forgotten.
> > 
> 
> Fortunately those are false-positives:
> 
>  # modprobe i915
>  # echo scan > /debug/kmemleak
>  # cat /debug/kmemleak
>  (lots of "leaks")
>  # rmmod i915
>  # echo scan > /debug/kmemleak
>  # cat /debug/kmemleak
>  (no leaks)
> 
> All the memory allocated when loading the module is
> freed in trace_module_remove_events() at module unload.
> 
> But I haven't looked into how to suppress those false-postives.
> I'd like to, but I'm going to leave my office and won't be
> back until 26th..

It is probably caused by the fact that kmemleak doesn't scan the
mod->trace_events data in a module (the _ftrace_events section). It only
scans those sections beginning with .data and .bss in a module. Maybe we
should add "_ftrace_events" as well or just prefix it with ".data".

Something like below may fix this (untested):

diff --git a/kernel/module.c b/kernel/module.c
index 8b7d880..1449691 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2383,6 +2383,9 @@ 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, mod->trace_events,
+			   sizeof(*mod->trace_events) * mod->num_trace_events,
+			   GFP_KERNEL);
 #endif
 #ifdef CONFIG_FTRACE_MCOUNT_RECORD
 	/* sechdrs[0].sh_size is always zero */


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