syzbot has bisected this issue to:
commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3
Author: Baokun Li <[email protected]>
Date: Thu Jun 16 02:13:56 2022 +0000
ext4: fix use-after-free in ext4_xattr_set_entry
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1011bcf8980000
start commit: b947cc5bf6d7 Merge tag 'erofs-for-6.9-rc7-fixes' of git://..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1211bcf8980000
console output: https://syzkaller.appspot.com/x/log.txt?x=1411bcf8980000
kernel config: https://syzkaller.appspot.com/x/.config?x=d2f00edef461175
dashboard link: https://syzkaller.appspot.com/bug?extid=dd43bd0f7474512edc47
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11d2957f180000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1620ca40980000
Reported-by: [email protected]
Fixes: 67d7d8ad99be ("ext4: fix use-after-free in ext4_xattr_set_entry")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
On Tue 30-04-24 08:04:03, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3
> Author: Baokun Li <[email protected]>
> 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 <[email protected]>
SUSE Labs, CR