[syzbot] [isofs?] VFS: Busy inodes after unmount (use-after-free) (3)

[syzbot] [isofs?] VFS: Busy inodes after unmount (use-after-free) (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    30d4efb2f5a5 Merge tag 'for-linus-6.18-rc1-tag' of git://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1350d05b980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=5eb55ce880562a8c
dashboard link: https://syzkaller.appspot.com/bug?extid=1d79ebe5383fc016cf07
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14f17c14580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13d80a7c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b7f58792107b/disk-30d4efb2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9a0647491b90/vmlinux-30d4efb2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9829a72408d5/bzImage-30d4efb2.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/ec44ab2c5fdc/mount_0.gz

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

VFS: Busy inodes after unmount of loop0 (iso9660)
------------[ cut here ]------------
kernel BUG at fs/super.c:653!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 5985 Comm: syz-executor Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:generic_shutdown_super+0x2bc/0x2c0 fs/super.c:651
Code: 03 42 80 3c 28 00 74 08 4c 89 f7 e8 6e 32 f3 ff 49 8b 16 48 81 c3 d0 07 00 00 48 c7 c7 60 90 d8 8a 48 89 de e8 85 59 fe fe 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc9000419fd20 EFLAGS: 00010246
RAX: 0000000000000031 RBX: ffff88803956a7d0 RCX: 8b706059fb7f3300
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 1ffff110072ad51b R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff52000833f49 R12: 0000000000000000
R13: dffffc0000000000 R14: ffffffff8d5b82e0 R15: ffff88803956a8d8
FS:  0000555590698500(0000) GS:ffff888127125000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bb0ed4b1b8 CR3: 0000000028c78000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 kill_block_super+0x44/0x90 fs/super.c:1723
 deactivate_locked_super+0xb9/0x130 fs/super.c:474
 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318
 task_work_run+0x1d4/0x260 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43
 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
 do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff17a1f01f7
Code: a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 a8 ff ff ff f7 d8 64 89 02 b8
RSP: 002b:00007fff2497d5b8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00007ff17a271d7d RCX: 00007ff17a1f01f7
RDX: 0000000000000000 RSI: 0000000000000009 RDI: 00007fff2497d670
RBP: 00007fff2497d670 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000246 R12: 00007fff2497e700
R13: 00007ff17a271d7d R14: 000000000001bfd3 R15: 00007fff2497e740
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:generic_shutdown_super+0x2bc/0x2c0 fs/super.c:651
Code: 03 42 80 3c 28 00 74 08 4c 89 f7 e8 6e 32 f3 ff 49 8b 16 48 81 c3 d0 07 00 00 48 c7 c7 60 90 d8 8a 48 89 de e8 85 59 fe fe 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc9000419fd20 EFLAGS: 00010246
RAX: 0000000000000031 RBX: ffff88803956a7d0 RCX: 8b706059fb7f3300
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 1ffff110072ad51b R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff52000833f49 R12: 0000000000000000
R13: dffffc0000000000 R14: ffffffff8d5b82e0 R15: ffff88803956a8d8
FS:  0000555590698500(0000) GS:ffff888127125000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bb0ed4b1b8 CR3: 0000000028c78000 CR4: 00000000003526f0


---
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

Forwarded: [PATCH] isofs: fix inode leak caused by disconnected dentries from exportfs

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] isofs: fix inode leak caused by disconnected dentries from exportfs
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When open_by_handle_at() is used with iso9660 filesystems, exportfs
creates disconnected dentries during file handle resolution. If the
operation fails (e.g., with -ESTALE during reconnect_path()), these
dentries remain cached with their associated inodes.

During unmount, shrink_dcache_for_umount() does not fully evict these
disconnected dentries, leaving their inodes with non-zero reference
counts. This triggers the "VFS: Busy inodes after unmount" warning
and causes inode leaks that accumulate across mount/unmount cycles.

The issue occurs because:
1. open_by_handle_at() calls exportfs_decode_fh_raw() to resolve
   file handles
2. For iso9660 with Joliet extensions, this creates disconnected
   dentries for both primary (iso9660) and secondary (Joliet) root
   inodes
3. When path reconnection fails with -ESTALE, the dentries are left
   in DCACHE_DISCONNECTED state
4. shrink_dcache_for_umount() in generic_shutdown_super() does not
   aggressively evict these disconnected dentries
5. The associated inodes (typically root inodes 1792 and 1807)
   remain with i_count=1, triggering the busy inode check

Add explicit shrink_dcache_sb() call in isofs_put_super() to ensure
all cached dentries, including disconnected ones created by exportfs
operations, are released before the superblock is destroyed.

Reported-by: syzbot+1d79ebe5383fc016cf07@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/isofs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c
index 6f0e6b19383c..bee410705442 100644
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -52,6 +52,7 @@ static int isofs_dentry_cmp_ms(const struct dentry *dentry,
 static void isofs_put_super(struct super_block *sb)
 {
 	struct isofs_sb_info *sbi = ISOFS_SB(sb);
+	shrink_dcache_sb(sb);
 
 #ifdef CONFIG_JOLIET
 	unload_nls(sbi->s_nls_iocharset);
-- 
2.43.0