[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240207121202.3142524-1-alexious@zju.edu.cn>
Date: Wed, 7 Feb 2024 20:12:00 +0800
From: Zhipeng Lu <alexious@....edu.cn>
To: alexious@....edu.cn
Cc: Desmond Cheong Zhi Xi <desmondcheongzx@...il.com>,
Viacheslav Dubeyko <slava@...eyko.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH] [v3] hfs: fix a memleak in hfs_find_init
If hfs_find_init succeeds but some other function called after it fails,
the overall cleanup function of hfs_find_init (i.e. hfs_find_exit) will
be called and `fd->search_key` is freed. However, if hfs_find_init fails
and returns an error, neither external nor internal deallocation of
`fd->search_key` is triggered.
This observation suggests that there could be a memleak problem in
hfs_find_init. In this patch, we add the missing deallocation in the
error-handling path (i.e. the default branch of the switch statement) to
prevent such memory leak.
Fixes: b3b2177a2d79 ("hfs: add lock nesting notation to hfs_find_init")
Signed-off-by: Zhipeng Lu <alexious@....edu.cn>
---
Changelog:
v2: Improve commit message to be more clear.
v3: Update commit message.
---
fs/hfs/bfind.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c
index ef9498a6e88a..7aa3b9aba4d1 100644
--- a/fs/hfs/bfind.c
+++ b/fs/hfs/bfind.c
@@ -36,6 +36,7 @@ int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd)
mutex_lock_nested(&tree->tree_lock, ATTR_BTREE_MUTEX);
break;
default:
+ kfree(fd->search_key);
return -EINVAL;
}
return 0;
--
2.34.1
Powered by blists - more mailing lists