linux-ext4 - Re: [syzbot] [ext4?] WARNING in mb_cache

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240502103341.t53u6ya7ujbzkkxo@quack3>
Date: Thu, 2 May 2024 12:33:41 +0200
From: Jan Kara <jack@...e.cz>
To: syzbot <syzbot+dd43bd0f7474512edc47@...kaller.appspotmail.com>
Cc: adilger.kernel@...ger.ca, jack@...e.cz, libaokun1@...wei.com,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	nathan@...nel.org, ndesaulniers@...gle.com, ritesh.list@...il.com,
	syzkaller-bugs@...glegroups.com, trix@...hat.com, tytso@....edu
Subject: Re: [syzbot] [ext4?] WARNING in mb_cache_destroy

On Tue 30-04-24 08:04:03, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3
> Author: Baokun Li <libaokun1@...wei.com>
> Date:   Thu Jun 16 02:13:56 2022 +0000
> 
>     ext4: fix use-after-free in ext4_xattr_set_entry

So I'm not sure the bisect is correct since the change is looking harmless.
But it is sufficiently related that there indeed may be some relationship.
Anyway, the kernel log has:

[   44.932900][ T1063] EXT4-fs warning (device loop0): ext4_evict_inode:297: xattr delete (err -12)
[   44.943316][ T1063] EXT4-fs (loop0): unmounting filesystem.
[   44.949531][ T1063] ------------[ cut here ]------------
[   44.955050][ T1063] WARNING: CPU: 0 PID: 1063 at fs/mbcache.c:409 mb_cache_destroy+0xda/0x110

So ext4_xattr_delete_inode() called when removing inode has failed with
ENOMEM and later mb_cache_destroy() was eventually complaining about having
mbcache entry with increased refcount. So likely some error cleanup path is
forgetting to drop mbcache entry reference somewhere but at this point I
cannot find where. We'll likely need to play with the reproducer to debug
that. Baokun, any chance for looking into this?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR