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;
Subject: Re: [PATCH] ubifs: Fix memory leak in do_rename
To:     =?UTF-8?Q?M=c3=a5rten_Lindahl?= <marten.lindahl@axis.com>,
        Richard Weinberger <richard@nod.at>
CC:     <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        <kernel@axis.com>
References: <20230330-memleak_rename-fix-v1-1-99789e908fdf@axis.com>
From:   Zhihao Cheng <chengzhihao1@huawei.com>
Message-ID: <bc8aaf0a-0b21-99a8-4c50-92edeff8edd7@huawei.com>
Date:   Thu, 30 Mar 2023 22:17:51 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20230330-memleak_rename-fix-v1-1-99789e908fdf@axis.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

> If renaming a file in an encrypted directory, function
> fscrypt_setup_filename allocates memory for a file name. This name is
> never used, and before returning to the caller the memory for it 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 'rename' that renames a
> file in an encrypted directory:
> 
>    unreferenced object 0xffff888101502840 (size 32):
>      comm "rename", pid 9404, jiffies 4302582475 (age 435.735s)
>      backtrace:
>        __kmem_cache_alloc_node
>        __kmalloc
>        fscrypt_setup_filename
>        do_rename
>        ubifs_rename
>        vfs_rename
>        do_renameat2
> 
> To fix this we can remove the call to fscrypt_setup_filename as it's not
> needed.
> 
> Reported-by: Zhihao Cheng <chengzhihao1@huawei.com>
> Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
> ---
>   fs/ubifs/dir.c | 6 ------
>   1 file changed, 6 deletions(-)
> 

I'm okay with this modification. It would be better to add a fix tag. 
(Fixes: 278d9a243635f26 ("ubifs: Rename whiteout atomically"))


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

> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
> index 0f29cf201136..4c2dda1346e7 100644
> --- a/fs/ubifs/dir.c
> +++ b/fs/ubifs/dir.c
> @@ -358,7 +358,6 @@ static struct inode *create_whiteout(struct inode *dir, struct dentry *dentry)
>   	umode_t mode = S_IFCHR | WHITEOUT_MODE;
>   	struct inode *inode;
>   	struct ubifs_info *c = dir->i_sb->s_fs_info;
> -	struct fscrypt_name nm;
>   
>   	/*
>   	 * Create an inode('nlink = 1') for whiteout without updating journal,
> @@ -369,10 +368,6 @@ static struct inode *create_whiteout(struct inode *dir, struct dentry *dentry)
>   	dbg_gen("dent '%pd', mode %#hx in dir ino %lu",
>   		dentry, mode, dir->i_ino);
>   
> -	err = fscrypt_setup_filename(dir, &dentry->d_name, 0, &nm);
> -	if (err)
> -		return ERR_PTR(err);
> -
>   	inode = ubifs_new_inode(c, dir, mode, false);
>   	if (IS_ERR(inode)) {
>   		err = PTR_ERR(inode);
> @@ -395,7 +390,6 @@ static struct inode *create_whiteout(struct inode *dir, struct dentry *dentry)
>   	make_bad_inode(inode);
>   	iput(inode);
>   out_free:
> -	fscrypt_free_filename(&nm);
>   	ubifs_err(c, "cannot create whiteout file, error %d", err);
>   	return ERR_PTR(err);
>   }
> 
> ---
> base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
> change-id: 20230330-memleak_rename-fix-6f94a6f99350
> 
> Best regards,
>