linux-kernel - Re: Possible memory leak via inotify_add

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: <1246921140.2866.88.camel@dhcp235-23.rdu.redhat.com>
Date:	Mon, 06 Jul 2009 18:59:00 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Possible memory leak via inotify_add_watch

On Mon, 2009-07-06 at 23:03 +0100, Catalin Marinas wrote:
> Hi Eric,
> 
> I'm getting a few kmemleak reports like the one below (it may as well
> be just a false positive). All of these allocations happened during
> udevd.

Ok, I'll take a look.  I know it highly unlikely but possible to leak in
sys_inotify_add_watch on some of the error paths.  Seeing as how you
object has a mask it was at some point actually attached to an inode and
was removed.  Since free_i_list is still unused that means it was
removed by an explicit request from inotify (inotify_rm_watch I guess),
not from the inode disappearing.  I'll try to run it down exactly
tonight.

-Eric


> unreferenced object 0xc399fd80 (size 84):
>   comm "udevd", pid 879, jiffies 4294897228
>   backtrace:
>     [<c01e0c3a>] create_object+0xfa/0x250
>     [<c01e1e7d>] kmemleak_alloc+0x5d/0x70
>     [<c01dac1b>] kmem_cache_alloc+0x14b/0x190
>     [<c0213800>] sys_inotify_add_watch+0xc0/0x2a0
>     [<c010300c>] sysenter_do_call+0x12/0x38
>     [<ffffffff>] 0xffffffff
> 
> Printing this object with gdb on /proc/kcore shows:
> 
> (gdb) print {struct inotify_inode_mark_entry}0xc399fd80
> $2 = {fsn_entry = {mask = 134250504, refcnt = {counter = 1}, inode = 0x0,
>     group = 0x0, i_list = {next = 0x0, pprev = 0x0}, g_list = {
>       next = 0xc399fd98, prev = 0xc399fd98}, lock = {raw_lock = {
>         slock = 1028}, magic = 3735899821, owner_cpu = 4294967295,
>       owner = 0xffffffff, dep_map = {key = 0xc0d3e59c, class_cache = 0x0,
>         name = 0xc068413d "&entry->lock"}}, free_i_list = {next = 0x6b6b6b6b,
>       prev = 0x6b6b6b6b}, free_g_list = {next = 0x6b6b6b6b,
>       prev = 0x6b6b6b6b}, free_mark = 0xc0213720 <inotify_free_mark>}, wd = 28}
> 
> It seems that is was freed via fsnotify_destroy_mark_by_entry() since
> group and inode members are NULL and it was removed from any list. The
> fsn_entry.refcnt, however, is still 1. Kmemleak cannot find any
> pointer to this object (though it doesn't track alloc_pages memory
> blocks).
> 
> Thanks.
> 

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