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 09:45:17 +0200
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Catalin Marinas <catalin.marinas@....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

2009/10/15 Catalin Marinas <catalin.marinas@....com>:
> 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 */
>
>

Yep - I've assume it could be also a problem of missing memory segment
in kmemleak scanning routine - but it was weird that just these two
modules (i915 & kvm) are doing such strange thing.

I've tested patch above with added cast  ( (unsigned
long)mod->trace_events) to pacify warning - but it did not helped -
leaks are still printed.

And I add another leak - which might be from the same range of problem :
(it's also present many times - and it even looks like hex dump is
changing so it's probably even frequently used memory region - at
least in few such objects)

unreferenced object 0xffff88013aa4ad80 (size 192):
  comm "swapper", pid 1, jiffies 4294877809
  hex dump (first 32 bytes):
    c0 dc a4 3a 01 88 ff ff 00 0c 79 39 01 88 ff ff  ...:......y9....
    90 00 cf 3a 01 88 ff ff 02 00 00 00 00 00 00 00  ...:............
  backtrace:
    [<ffffffff8140e9a6>] kmemleak_alloc+0x26/0x60
    [<ffffffff81126a01>] kmem_cache_alloc_notrace+0xc1/0x140
    [<ffffffff8127256a>] dma_debug_init+0x23a/0x3a0
    [<ffffffff81864a37>] pci_iommu_init+0xe/0x28
    [<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
    [<ffffffff8185f4e6>] kernel_init+0x150/0x1a6
    [<ffffffff8100d21a>] child_rip+0xa/0x20
    [<ffffffffffffffff>] 0xffffffffffffffff


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