linux-kernel - Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-id: <20140828014736.GA6808@lcm>
Date:	Thu, 28 Aug 2014 10:47:36 +0900
From:	Changman Lee <cm224.lee@...sung.com>
To:	Chao Yu <chao2.yu@...sung.com>
Cc:	Jaegeuk Kim <jaegeuk@...nel.org>, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to prevent
 accessing invalid inode

Hi Chao,

I agree it's correct unlock_new_inode should be located after make_bad_inode.

About this scenario,
I think we should check some condition if this could be occured;
A inode allocated newly could be victim by gc thread.
Then, f2fs_iget called by Thread A have to fail because we handled it as
bad_inode in Thread B. However, f2fs_iget could still get inode.
How about check it using is_bad_inode() in f2fs_iget.

Thanks,

On Tue, Aug 26, 2014 at 06:35:29PM +0800, Chao Yu wrote:
> As the race condition on the inode cache, following scenario can appear:
> [Thread a]				[Thread b]
> 					->f2fs_mkdir
> 					  ->f2fs_add_link
> 					    ->__f2fs_add_link
> 					      ->init_inode_metadata failed here
> ->gc_thread_func
>   ->f2fs_gc
>     ->do_garbage_collect
>       ->gc_data_segment
>         ->f2fs_iget
>           ->iget_locked
>             ->wait_on_inode
> 					  ->unlock_new_inode
>         ->move_data_page
> 					  ->make_bad_inode
> 					  ->iput
> 
> When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode
> should be set as bad to avoid being accessed by other thread. But in above
> scenario, it allows f2fs to access the invalid inode before this inode was set
> as bad.
> This patch fix the potential problem, and this issue was found by code review.
> 
> Signed-off-by: Chao Yu <chao2.yu@...sung.com>
> ---
>  fs/f2fs/namei.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 6b53ce9..845f1be 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -134,8 +134,8 @@ static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
>  	return 0;
>  out:
>  	clear_nlink(inode);
> -	unlock_new_inode(inode);
>  	make_bad_inode(inode);
> +	unlock_new_inode(inode);
>  	iput(inode);
>  	alloc_nid_failed(sbi, ino);
>  	return err;
> @@ -267,8 +267,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry *dentry,
>  	return err;
>  out:
>  	clear_nlink(inode);
> -	unlock_new_inode(inode);
>  	make_bad_inode(inode);
> +	unlock_new_inode(inode);
>  	iput(inode);
>  	alloc_nid_failed(sbi, inode->i_ino);
>  	return err;
> @@ -308,8 +308,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
>  out_fail:
>  	clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
>  	clear_nlink(inode);
> -	unlock_new_inode(inode);
>  	make_bad_inode(inode);
> +	unlock_new_inode(inode);
>  	iput(inode);
>  	alloc_nid_failed(sbi, inode->i_ino);
>  	return err;
> @@ -354,8 +354,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry *dentry,
>  	return 0;
>  out:
>  	clear_nlink(inode);
> -	unlock_new_inode(inode);
>  	make_bad_inode(inode);
> +	unlock_new_inode(inode);
>  	iput(inode);
>  	alloc_nid_failed(sbi, inode->i_ino);
>  	return err;
> @@ -688,8 +688,8 @@ release_out:
>  out:
>  	f2fs_unlock_op(sbi);
>  	clear_nlink(inode);
> -	unlock_new_inode(inode);
>  	make_bad_inode(inode);
> +	unlock_new_inode(inode);
>  	iput(inode);
>  	alloc_nid_failed(sbi, inode->i_ino);
>  	return err;
> -- 
> 2.0.0.421.g786a89d
> 
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/