[syzbot] [fs?] possible deadlock in __simple_recursive_removal

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 50c8770a42fa Add linux-next specific files for 20250702
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=152d348c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=70c16e4e191115d4
dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=106bd770580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164b048c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3d4ef6bedc5b/disk-50c8770a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/15b7565dc0ef/vmlinux-50c8770a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3b397342a62b/bzImage-50c8770a.xz

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

============================================
WARNING: possible recursive locking detected
6.16.0-rc4-next-20250702-syzkaller #0 Not tainted
--------------------------------------------
syz-executor365/5837 is trying to acquire lock:
ffff8880792cc650 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
ffff8880792cc650 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: __simple_recursive_removal+0x95/0x510 fs/libfs.c:614

but task is already holding lock:
ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: bm_entry_write+0x289/0x540 fs/binfmt_misc.c:737

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(&sb->s_type->i_mutex_key#15);
lock(&sb->s_type->i_mutex_key#15);

*** DEADLOCK ***

May be due to missing lock nesting notation

2 locks held by syz-executor365/5837:
#0: ffff88807e5fc428 (sb_writers#8){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:3098 [inline]
#0: ffff88807e5fc428 (sb_writers#8){.+.+}-{0:0}, at: vfs_write+0x211/0xa90 fs/read_write.c:682
#1: ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:869 [inline]
#1: ffff888027bf0148 (&sb->s_type->i_mutex_key#15){+.+.}-{4:4}, at: bm_entry_write+0x289/0x540 fs/binfmt_misc.c:737

stack backtrace:
CPU: 0 UID: 0 PID: 5837 Comm: syz-executor365 Not tainted 6.16.0-rc4-next-20250702-syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_deadlock_bug+0x28b/0x2a0 kernel/locking/lockdep.c:3044
check_deadlock kernel/locking/lockdep.c:3096 [inline]
validate_chain+0x1a3f/0x2140 kernel/locking/lockdep.c:3898
__lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
down_write+0x96/0x1f0 kernel/locking/rwsem.c:1577
inode_lock include/linux/fs.h:869 [inline]
__simple_recursive_removal+0x95/0x510 fs/libfs.c:614
remove_binfmt_handler fs/binfmt_misc.c:694 [inline]
bm_entry_write+0x4f7/0x540 fs/binfmt_misc.c:749
vfs_write+0x27e/0xa90 fs/read_write.c:684
ksys_write+0x145/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f147e7aa369
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffed0db9fa8 EFLAGS: 00000246 ORIG_RAX


---
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 syzk...@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

[Al Viro]

On Wed, Jul 02, 2025 at 11:04:33AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 50c8770a42fa Add linux-next specific files for 20250702
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=152d348c580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=70c16e4e191115d4
> dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
> compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=106bd770580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164b048c580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/3d4ef6bedc5b/disk-50c8770a.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/15b7565dc0ef/vmlinux-50c8770a.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3b397342a62b/bzImage-50c8770a.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+6d7771...@syzkaller.appspotmail.com
>
> ============================================
> WARNING: possible recursive locking detected
> 6.16.0-rc4-next-20250702-syzkaller #0 Not tainted

False positive. locked_recursive_removal() is called with ->i_rwsem
on the victim's parent. It will grab and release ->i_rwsem on
descendents of victim and victim itself (never more than one held
simultaneously) and it is used only on filesystems where we never
change the tree topology. So the normal ordering of ->i_rwsem is
upheld there.

Proper annotations would be to have the lock on parent grabbed with
I_MUTEX_PARENT as class...

[Lizhi Xu]

#syz test

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index 760437a91648..537390c984ee 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -734,7 +734,7 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
case 3:
/* Delete this handler. */
inode = d_inode(inode->i_sb->s_root);
- inode_lock(inode);
+ inode_lock_nested(inode, I_MUTEX_PARENT);

/*
* In order to add new element or remove elements from the list
diff --git a/fs/libfs.c b/fs/libfs.c
index 3bc6c3750b47..0e3e33c4f159 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -611,7 +611,7 @@ static void __simple_recursive_removal(struct dentry *dentry,
struct dentry *victim = NULL, *child;
struct inode *inode = this->d_inode;

- inode_lock(inode);
+ inode_lock_nested(inode, I_MUTEX_CHILD);
if (d_is_dir(this))
inode->i_flags |= S_DEAD;
while ((child = find_next_child(this, victim)) == NULL) {
@@ -624,7 +624,7 @@ static void __simple_recursive_removal(struct dentry *dentry,
this = this->d_parent;
inode = this->d_inode;
if (!locked || victim != dentry)
- inode_lock(inode);
+ inode_lock_nested(inode, I_MUTEX_CHILD);
if (simple_positive(victim)) {
d_invalidate(victim); // avoid lost mounts
if (callback)

[Lizhi Xu]

#syz test

diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 0bd1df2ebb47..e30270e5883a 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -175,7 +175,7 @@ rpc_close_pipes(struct dentry *dentry)
int need_release;
LIST_HEAD(free_list);

- inode_lock(inode);
+ inode_lock_nested(inode, I_MUTEX_CHILD);

spin_lock(&pipe->lock);
need_release = pipe->nreaders != 0 || pipe->nwriters != 0;
pipe->nreaders = 0;

[syzbot]

Hello,

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

Reported-by: syzbot+6d7771...@syzkaller.appspotmail.com
Tested-by: syzbot+6d7771...@syzkaller.appspotmail.com

Tested on:

commit: 50c8770a Add linux-next specific files for 20250702
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=110a33d4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=76d012e863976d4c
dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch: https://syzkaller.appspot.com/x/patch.diff?x=126bb48c580000

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

[Lizhi Xu]

#syz test

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c

index 760437a91648..64dc551681b9 100644

--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -734,7 +734,7 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
case 3:
/* Delete this handler. */
inode = d_inode(inode->i_sb->s_root);
- inode_lock(inode);
+ inode_lock_nested(inode, I_MUTEX_PARENT);

/*
* In order to add new element or remove elements from the list

@@ -803,7 +803,7 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
e->interp_file = f;
}

- inode_lock(d_inode(root));
+ inode_lock_nested(d_inode(root), I_MUTEX_PARENT);
dentry = lookup_noperm(&QSTR(e->name), root);
err = PTR_ERR(dentry);
if (IS_ERR(dentry))

[syzbot]

Hello,

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

Reported-by: syzbot+6d7771...@syzkaller.appspotmail.com
Tested-by: syzbot+6d7771...@syzkaller.appspotmail.com

Tested on:

commit: 8d6c5833 Add linux-next specific files for 20250703
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17e40582580000
kernel config: https://syzkaller.appspot.com/x/.config?x=223eb69834aa2df6

dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

patch: https://syzkaller.appspot.com/x/patch.diff?x=127ff982580000

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file fs/binfmt_misc.c
Hunk #1 FAILED at 734.
1 out of 2 hunks FAILED

Tested on:

commit: 8d6c5833 Add linux-next specific files for 20250703
git tree: linux-next

kernel config: https://syzkaller.appspot.com/x/.config?x=70c16e4e191115d4

dashboard link: https://syzkaller.appspot.com/bug?extid=6d7771315ecb9233f395
compiler:

patch: https://syzkaller.appspot.com/x/patch.diff?x=12fff982580000

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.