Message ID | 20221022115211.1969429-1-lizetao1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1162415wrr; Sat, 22 Oct 2022 04:32:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7oC5Xkm7osI7tlcpR1rM71z7wta5VZv8OEE7LQXoVL86oYHhhTKOuIYjAHlhqwFzlhNVWO X-Received: by 2002:a63:4283:0:b0:457:dced:8ba3 with SMTP id p125-20020a634283000000b00457dced8ba3mr19939221pga.220.1666438347539; Sat, 22 Oct 2022 04:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666438347; cv=none; d=google.com; s=arc-20160816; b=gwSUt4XEJJH9/+SOyG/IgeKkgkkBwc8iaEyvrscxl/NcGS/LhdpAv5xIoL4+vRCnWu HgvY7uKaCmG02K/M18/sPk3q27/aAdi7MbShkJiVdlADX+kGzLpU0/KnrXeIGg88cK3o l2SsJIZkmLdg6QfQalqKkxfLwvfS5dV+h2Yqw1S1IKzaTLNU8Zq5KpcaA0JuWXZVnm7+ c7dsnDGiZy8MBuj6JxgPuToTIxDoBAl1BGI2QGIYg1AnAUrFbm2Hkfo1tmHnmhLDYwWO 43dEV8rQMtSIDhs1hqxbcrpH62fNP+sEhxR9VsxLyJsIp6HRewV/UIjadfW7UOCt4HFU 8xag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Ho8MmyOvcBFa7zPpKdnLVB+opBkp9kUOntnjEcSHQy8=; b=vMWVIkr+yq7ofSyOmJnho5iqafayrh2TtGL/eJvQJRodE1tIkflxeuqch40XErVCij C8958YOfXKFnK/4E8P2hz5XWAHoc8dG5DAaD7AeAfL8kMOUfNjENrPfjATCvHXYvQkHf QW3ICFXsFr/PKqdHdSJ3Axs2vAFv5I64qE/unCCO9yG3NuOizxrjg876cmN2iK44uouF 0hv5Js+eLwgAjyjNTRr6LinltfLoYECW59jednbR7vf2SIp4uStp/zDUsVFl1nNlWYA8 SK2ObJtgMmDwuNPIuhIm0bc+YeaxPUWOB55msk7kobaBlPayUvzR9eMbQMhgxnw3b96H QgqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j10-20020a170902da8a00b0017f97fe778dsi31629633plx.126.2022.10.22.04.32.15; Sat, 22 Oct 2022 04:32:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230197AbiJVLVY (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 22 Oct 2022 07:21:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230346AbiJVLU6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 22 Oct 2022 07:20:58 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E347EA9C8 for <linux-kernel@vger.kernel.org>; Sat, 22 Oct 2022 03:48:59 -0700 (PDT) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4MvdKz0PMgzJn3b; Sat, 22 Oct 2022 18:46:15 +0800 (CST) Received: from huawei.com (10.175.101.6) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 22 Oct 2022 18:48:56 +0800 From: Li Zetao <lizetao1@huawei.com> To: <richard@nod.at>, <Artem.Bityutskiy@nokia.com>, <ext-adrian.hunter@nokia.com> CC: <lizetao1@huawei.com>, <yi.zhang@huawei.com>, <chengzhihao1@huawei.com>, <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] ubifs: Fix memory leak in alloc_wbufs() Date: Sat, 22 Oct 2022 19:52:11 +0800 Message-ID: <20221022115211.1969429-1-lizetao1@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.101.6] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747387256680364853?= X-GMAIL-MSGID: =?utf-8?q?1747387256680364853?= |
Series |
ubifs: Fix memory leak in alloc_wbufs()
|
|
Commit Message
Li Zetao
Oct. 22, 2022, 11:52 a.m. UTC
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@huawei.com>
---
fs/ubifs/super.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
Comments
在 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@huawei.com> > --- > fs/ubifs/super.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index d0c9a09988bc..32cb14759796 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -833,7 +833,7 @@ static int alloc_wbufs(struct ubifs_info *c) INIT_LIST_HEAD(&c->jheads[i].buds_list); err = ubifs_wbuf_init(c, &c->jheads[i].wbuf); if (err) - return err; + goto out_wbuf; c->jheads[i].wbuf.sync_callback = &bud_wbuf_callback; c->jheads[i].wbuf.jhead = i; @@ -841,7 +841,7 @@ static int alloc_wbufs(struct ubifs_info *c) c->jheads[i].log_hash = ubifs_hash_get_desc(c); if (IS_ERR(c->jheads[i].log_hash)) { err = PTR_ERR(c->jheads[i].log_hash); - goto out; + goto out_log_hash; } } @@ -854,9 +854,18 @@ static int alloc_wbufs(struct ubifs_info *c) return 0; -out: - while (i--) +out_log_hash: + kfree(c->jheads[i].wbuf.buf); + kfree(c->jheads[i].wbuf.inodes); + +out_wbuf: + while (i--) { + kfree(c->jheads[i].wbuf.buf); + kfree(c->jheads[i].wbuf.inodes); kfree(c->jheads[i].log_hash); + } + kfree(c->jheads); + c->jheads = NULL; return err; }