linux-kernel - Re: [PATCH AUTOSEL 5.11 03/44] ext4: add reclaim checks to xattr code

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: <20210325143020.GC13673@quack2.suse.cz>
Date:   Thu, 25 Mar 2021 15:30:20 +0100
From:   Jan Kara <jack@...e.cz>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jan Kara <jack@...e.cz>, Theodore Ts'o <tytso@....edu>,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.11 03/44] ext4: add reclaim checks to xattr code

Sasha, just be aware that this commit was added to help tracking down a
particular syzbot report. As such there's no point in carrying it in
-stable but there's no big harm either... Just one patch more.

								Honza

On Thu 25-03-21 07:24:18, Sasha Levin wrote:
> From: Jan Kara <jack@...e.cz>
> 
> [ Upstream commit 163f0ec1df33cf468509ff38cbcbb5eb0d7fac60 ]
> 
> Syzbot is reporting that ext4 can enter fs reclaim from kvmalloc() while
> the transaction is started like:
> 
>   fs_reclaim_acquire+0x117/0x150 mm/page_alloc.c:4340
>   might_alloc include/linux/sched/mm.h:193 [inline]
>   slab_pre_alloc_hook mm/slab.h:493 [inline]
>   slab_alloc_node mm/slub.c:2817 [inline]
>   __kmalloc_node+0x5f/0x430 mm/slub.c:4015
>   kmalloc_node include/linux/slab.h:575 [inline]
>   kvmalloc_node+0x61/0xf0 mm/util.c:587
>   kvmalloc include/linux/mm.h:781 [inline]
>   ext4_xattr_inode_cache_find fs/ext4/xattr.c:1465 [inline]
>   ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1508 [inline]
>   ext4_xattr_set_entry+0x1ce6/0x3780 fs/ext4/xattr.c:1649
>   ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224
>   ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380
>   ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493
> 
> This should be impossible since transaction start sets PF_MEMALLOC_NOFS.
> Add some assertions to the code to catch if something isn't working as
> expected early.
> 
> Link: https://lore.kernel.org/linux-ext4/000000000000563a0205bafb7970@google.com/
> Signed-off-by: Jan Kara <jack@...e.cz>
> Link: https://lore.kernel.org/r/20210222171626.21884-1-jack@suse.cz
> Signed-off-by: Theodore Ts'o <tytso@....edu>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>  fs/ext4/xattr.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 372208500f4e..083c95126781 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1462,6 +1462,9 @@ ext4_xattr_inode_cache_find(struct inode *inode, const void *value,
>  	if (!ce)
>  		return NULL;
>  
> +	WARN_ON_ONCE(ext4_handle_valid(journal_current_handle()) &&
> +		     !(current->flags & PF_MEMALLOC_NOFS));
> +
>  	ea_data = kvmalloc(value_len, GFP_KERNEL);
>  	if (!ea_data) {
>  		mb_cache_entry_put(ea_inode_cache, ce);
> @@ -2327,6 +2330,7 @@ ext4_xattr_set_handle(handle_t *handle, struct inode *inode, int name_index,
>  			error = -ENOSPC;
>  			goto cleanup;
>  		}
> +		WARN_ON_ONCE(!(current->flags & PF_MEMALLOC_NOFS));
>  	}
>  
>  	error = ext4_reserve_inode_write(handle, inode, &is.iloc);
> -- 
> 2.30.1
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR