linux-kernel - Re: [PATCH] ubifs: Fix memory leak in alloc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f4a4e992-9efd-b4ca-1788-efe99e4b7d87@huawei.com>
Date:   Mon, 24 Oct 2022 09:31:46 +0800
From:   Zhihao Cheng <chengzhihao1@...wei.com>
To:     Li Zetao <lizetao1@...wei.com>, <richard@....at>,
        <Artem.Bityutskiy@...ia.com>, <ext-adrian.hunter@...ia.com>
CC:     <yi.zhang@...wei.com>, <linux-mtd@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ubifs: Fix memory leak in alloc_wbufs()

在 2022/10/22 19:52, Li Zetao 写道:
> kmemleak reported a sequence of memory leaks, and show them as following:
> 
>    unreferenced object 0xffff8881575f8400 (size 1024):
>      comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)
>      hex dump (first 32 bytes):
>        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>      backtrace:
>        [<ffffffff8176cecd>] __kmalloc+0x4d/0x150
>        [<ffffffffa0406b2b>] ubifs_mount+0x307b/0x7170 [ubifs]
>        [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0
>        [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230
>        [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0
>        [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270
>        [<ffffffff83c14295>] do_syscall_64+0x35/0x80
>        [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
> 
>    unreferenced object 0xffff8881798a6e00 (size 512):
>      comm "mount", pid 19677, jiffies 4297121912 (age 37.816s)
>      hex dump (first 32 bytes):
>        6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
>        6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
>      backtrace:
>        [<ffffffff8176cecd>] __kmalloc+0x4d/0x150
>        [<ffffffffa0418342>] ubifs_wbuf_init+0x52/0x480 [ubifs]
>        [<ffffffffa0406ca5>] ubifs_mount+0x31f5/0x7170 [ubifs]
>        [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0
>        [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230
>        [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0
>        [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270
>        [<ffffffff83c14295>] do_syscall_64+0x35/0x80
>        [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
> 
> The problem is that the ubifs_wbuf_init() returns an error in the
> loop which in the alloc_wbufs(), then the wbuf->buf and wbuf->inodes
> that were successfully alloced before are not freed.
> 
> Fix it by adding error hanging path in alloc_wbufs() which frees
> the memory alloced before when ubifs_wbuf_init() returns an error.
> 
> Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
> Signed-off-by: Li Zetao <lizetao1@...wei.com>
> ---
>   fs/ubifs/super.c | 17 +++++++++++++----
>   1 file changed, 13 insertions(+), 4 deletions(-)

Reviewed-by: Zhihao Cheng <chengzhihao1@...wei.com>