[syzbot] [btrfs?] VFS: Busy inodes after unmount (use-after-free) (2)

[syzbot] [btrfs?] VFS: Busy inodes after unmount (use-after-free) (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    e0f4c8dd9d2d Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1481fb68580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=868079b7b8989c3c
dashboard link: https://syzkaller.appspot.com/bug?extid=1134d3a5b062e9665a7a
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10edfa70580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115a84d4580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/463c704c2ee6/disk-e0f4c8dd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1bb99dd967d9/vmlinux-e0f4c8dd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/505fe552b9a8/Image-e0f4c8dd.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/3eef91541df5/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=176dfa70580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1134d3a5b062e9665a7a@syzkaller.appspotmail.com

BTRFS info (device loop0): last unmount of filesystem c9fe44da-de57-406a-8241-57ec7d4412cf
VFS: Busy inodes after unmount of loop0 (btrfs)
------------[ cut here ]------------
kernel BUG at fs/super.c:652!
Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
Modules linked in:
CPU: 1 UID: 0 PID: 6484 Comm: syz-executor107 Not tainted 6.15.0-rc4-syzkaller-ge0f4c8dd9d2d #0 PREEMPT 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : generic_shutdown_super+0x2b4/0x2b8 fs/super.c:650
lr : generic_shutdown_super+0x2b4/0x2b8 fs/super.c:650
sp : ffff8000a43f7ba0
x29: ffff8000a43f7ba0 x28: 00007dfe9b1ba808 x27: ffff80008f301de8
x26: ffffffffffffffff x25: dfff800000000000 x24: 1fffe00018b9bcf0
x23: ffff80008b2817e0 x22: dfff800000000000 x21: 0000000000000000
x20: ffff80008fa4d4c0 x19: ffff0000c5cde000 x18: 1fffe00036711a76
x17: ffff80008f2fe000 x16: ffff80008ada5d6c x15: 0000000000000001
x14: 1ffff0001487eee0 x13: 0000000000000000 x12: 0000000000000000
x11: ffff70001487eee1 x10: 0000000000ff0100 x9 : 9c3427ac6e3c7500
x8 : 9c3427ac6e3c7500 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a43f7538 x4 : ffff80008f3f4fa0 x3 : ffff800082faeee4
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000002f
Call trace:
 generic_shutdown_super+0x2b4/0x2b8 fs/super.c:650 (P)
 kill_anon_super+0x4c/0x7c fs/super.c:1237
 btrfs_kill_super+0x40/0x58 fs/btrfs/super.c:2099
 deactivate_locked_super+0xc4/0x12c fs/super.c:473
 deactivate_super+0xe0/0x100 fs/super.c:506
 cleanup_mnt+0x31c/0x3ac fs/namespace.c:1435
 __cleanup_mnt+0x20/0x30 fs/namespace.c:1442
 task_work_run+0x1dc/0x260 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 do_notify_resume+0x16c/0x1ec arch/arm64/kernel/entry-common.c:151
 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
 exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
 el0_svc+0xb0/0x150 arch/arm64/kernel/entry-common.c:745
 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Code: b0051160 91350000 9119a261 97cfbb64 (d4210000) 
---[ end trace 0000000000000000 ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [btrfs?] VFS: Busy inodes after unmount (use-after-free) (2)

[Tetsuo Handa]

#syz test

Subject: [PATCH v2] ocfs2: update d_splice_alias() return code checking

When commit d3556babd7fa ("ocfs2: fix d_splice_alias() return code
checking") was merged into v3.18-rc3, d_splice_alias() was returning
one of a valid dentry, NULL or an ERR_PTR.

When commit b5ae6b15bd73 ("merge d_materialise_unique() into
d_splice_alias()") was merged into v3.19-rc1, d_splice_alias() started
returning -ELOOP as one of ERR_PTR values.

Now, when syzkaller mounts a crafted ocfs2 filesystem image that hits
d_splice_alias() == -ELOOP case from ocfs2_lookup(), ocfs2_lookup() fails
to handle -ELOOP case and generic_shutdown_super() hits "VFS: Busy inodes
after unmount" message.

Instead of calling ocfs2_dentry_attach_lock() or ocfs2_dentry_attach_gen()
when d_splice_alias() returned an ERR_PTR value, change ocfs2_lookup() to
bail out immediately.

Also, ocfs2_lookup() needs to call dupt() when ocfs2_dentry_attach_lock()
returned an ERR_PTR value.

Reported-by: syzbot <syzbot+1134d3a5b062e9665a7a@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=1134d3a5b062e9665a7a
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 fs/ocfs2/namei.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index 99278c8f0e24..f75fd19974bc 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -142,6 +142,8 @@ static struct dentry *ocfs2_lookup(struct inode *dir, struct dentry *dentry,
 
 bail_add:
 	ret = d_splice_alias(inode, dentry);
+	if (IS_ERR(ret))
+		goto bail_unlock;
 
 	if (inode) {
 		/*
@@ -154,13 +156,12 @@ static struct dentry *ocfs2_lookup(struct inode *dir, struct dentry *dentry,
 		 * NOTE: This dentry already has ->d_op set from
 		 * ocfs2_get_parent() and ocfs2_get_dentry()
 		 */
-		if (!IS_ERR_OR_NULL(ret))
-			dentry = ret;
-
-		status = ocfs2_dentry_attach_lock(dentry, inode,
+		status = ocfs2_dentry_attach_lock(ret ? ret : dentry, inode,
 						  OCFS2_I(dir)->ip_blkno);
 		if (status) {
 			mlog_errno(status);
+			if (ret)
+				dput(ret);
 			ret = ERR_PTR(status);
 			goto bail_unlock;
 		}
-- 
2.50.0

Re: [syzbot] [btrfs?] VFS: Busy inodes after unmount (use-after-free) (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1134d3a5b062e9665a7a@syzkaller.appspotmail.com
Tested-by: syzbot+1134d3a5b062e9665a7a@syzkaller.appspotmail.com

Tested on:

commit:         67a99386 Merge tag 'v6.16-p6' of git://git.kernel.org/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17e4708c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=28cc6f051378bb16
dashboard link: https://syzkaller.appspot.com/bug?extid=1134d3a5b062e9665a7a
compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1317f182580000

Note: testing is done by a robot and is best-effort only.