linux-kernel - Re: FUSE kmemleak report

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:	Tue, 6 Sep 2011 11:35:55 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Sitsofe Wheeler <sitsofe@...oo.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	fuse-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: FUSE kmemleak report

On 5 September 2011 23:37, Sitsofe Wheeler <sitsofe@...oo.com> wrote:
> kmemleak is reporting that 32 bytes are being leaked by FUSE:
>
> unreferenced object 0xe373b270 (size 32):
>  comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s)
>  hex dump (first 32 bytes):
>    01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
>    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>  backtrace:
>    [<b05517d7>] kmemleak_alloc+0x27/0x50
>    [<b0196435>] kmem_cache_alloc+0xc5/0x180
>    [<b02455be>] fuse_alloc_forget+0x1e/0x20
>    [<b0245670>] fuse_alloc_inode+0xb0/0xd0
>    [<b01b1a8c>] alloc_inode+0x1c/0x80
>    [<b01b290f>] iget5_locked+0x8f/0x1a0
>    [<b0246022>] fuse_iget+0x72/0x1a0
>    [<b02461da>] fuse_get_root_inode+0x8a/0x90
>    [<b02465cf>] fuse_fill_super+0x3ef/0x590
>    [<b019e56f>] mount_nodev+0x3f/0x90
>    [<b0244e95>] fuse_mount+0x15/0x20
>    [<b019d1bc>] mount_fs+0x1c/0xc0
>    [<b01b5811>] vfs_kern_mount+0x41/0x90
>    [<b01b5af9>] do_kern_mount+0x39/0xd0
>    [<b01b7585>] do_mount+0x2e5/0x660
>    [<b01b7966>] sys_mount+0x66/0xa0
>
> This leak report is consistent and happens once per boot on
> 3.1.0-rc5-dirty.

IIUC, kmemleak reports the fuse_forget_link that corresponds to the
root inode (allocated via fuse_fill_super). The root inode is later
freed (did the mount failed?) but not the forget link. I'm not
familiar with this code, so note exactly sure where the forget link
should have been freed.

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