diff options
| author | Mårten Lindahl <marten.lindahl@axis.com> | 2023-03-30 11:32:14 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2023-05-17 11:11:39 +0200 |
| commit | 8ad8c67a897e68426e85990ebfe0a7d1f71fc79f (patch) | |
| tree | 1f85bcd65f0ccf14de3ca3fa4f43d71a71ddbf7b /fs/ubifs | |
| parent | 3144855d46a825156fd0dae21d92bcd6d6fb89cd (diff) | |
| download | linux-stable-8ad8c67a897e68426e85990ebfe0a7d1f71fc79f.tar.gz linux-stable-8ad8c67a897e68426e85990ebfe0a7d1f71fc79f.tar.bz2 linux-stable-8ad8c67a897e68426e85990ebfe0a7d1f71fc79f.zip | |
ubifs: Free memory for tmpfile name
commit 1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3 upstream.
When opening a ubifs tmpfile on an encrypted directory, function
fscrypt_setup_filename allocates memory for the name that is to be
stored in the directory entry, but after the name has been copied to the
directory entry inode, the memory is not freed.
When running kmemleak on it we see that it is registered as a leak. The
report below is triggered by a simple program 'tmpfile' just opening a
tmpfile:
unreferenced object 0xffff88810178f380 (size 32):
comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s)
backtrace:
__kmem_cache_alloc_node
__kmalloc
fscrypt_setup_filename
ubifs_tmpfile
vfs_tmpfile
path_openat
Free this memory after it has been copied to the inode.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'fs/ubifs')
| -rw-r--r-- | fs/ubifs/dir.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 99e3692264ae..83822f281cdf 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -462,6 +462,7 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, mutex_unlock(&dir_ui->ui_mutex); ubifs_release_budget(c, &req); + fscrypt_free_filename(&nm); return 0; |