Re: [PATCH] ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

[Joseph Qi <joseph.qi@linux.alibaba.com>]

On 10/30/24 6:43 AM, Andrew Kanner wrote:
> Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():
> 
> [   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
> [   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry
> [   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
> [...]
> [   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
> [...]
> [   57.331328] Call Trace:
> [   57.331477]  <TASK>
> [...]
> [   57.333511]  ? do_user_addr_fault+0x3e5/0x740
> [   57.333778]  ? exc_page_fault+0x70/0x170
> [   57.334016]  ? asm_exc_page_fault+0x2b/0x30
> [   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
> [   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
> [   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0
> [   57.335164]  ocfs2_xa_set+0x704/0xcf0
> [   57.335381]  ? _raw_spin_unlock+0x1a/0x40
> [   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20
> [   57.335915]  ? trace_preempt_on+0x1e/0x70
> [   57.336153]  ? start_this_handle+0x16c/0x500
> [   57.336410]  ? preempt_count_sub+0x50/0x80
> [   57.336656]  ? _raw_read_unlock+0x20/0x40
> [   57.336906]  ? start_this_handle+0x16c/0x500
> [   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0
> [   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0
> [   57.337706]  ? ocfs2_start_trans+0x13d/0x290
> [   57.337971]  ocfs2_xattr_set+0xb13/0xfb0
> [   57.338207]  ? dput+0x46/0x1c0
> [   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30
> [   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30
> [   57.338948]  __vfs_removexattr+0x92/0xc0
> [   57.339182]  __vfs_removexattr_locked+0xd5/0x190
> [   57.339456]  ? preempt_count_sub+0x50/0x80
> [   57.339705]  vfs_removexattr+0x5f/0x100
> [...]
> 
> Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->
> ocfs2_xa_value_truncate() with -ENOMEM.
> 
> In this case the comment mentions that we can return 0 if
> ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
> anyway. But the following 'rc' check is wrong and execution flow do
> 'ocfs2_xa_remove_entry(loc);' twice:
> * 1st: in ocfs2_xa_cleanup_value_truncate();
> * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.
> 
> Fix this by skipping the 2nd removal of the same entry and making
> syzkaller repro happy.
> 
> Cc: stable@vger.kernel.org
> Fixes: 399ff3a748cf ("ocfs2: Handle errors while setting external xattr values.")
> Reported-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/671e13ab.050a0220.2b8c0f.01d0.GAE@google.com/T/
> Tested-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com
> Signed-off-by: Andrew Kanner <andrew.kanner@gmail.com>
> ---
>  fs/ocfs2/xattr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
> index dd0a05365e79..5bc4d660e15a 100644
> --- a/fs/ocfs2/xattr.c
> +++ b/fs/ocfs2/xattr.c
> @@ -2036,7 +2036,7 @@ static int ocfs2_xa_remove(struct ocfs2_xa_loc *loc,
>  				rc = 0;
>  			ocfs2_xa_cleanup_value_truncate(loc, "removing",
>  							orig_clusters);
> -			if (rc)
> +			if (rc == 0)

Seems in this case, we have to ignore rc and directly goto out?

Thanks,
Joseph

>  				goto out;
>  		}
>  	}