In fuse_dev_install_with_pq(), after updating the chan for the new device,
the fch->connected value for the old device is set to 0. This logic is
fundamentally flawed in cases where the new fd passed during a clone
operation is identical to the device file's fd; specifically, during
an unmount operation, this prevents fuse_conn_destroy() and subsequently
fuse_chan_abort() from terminating pending requests, and the wake-up of
the blocked_waitq is also consequently skipped. This triggers a timeout
in fuse_chan_wait_aborted() [1].

The original conditional logic has been restored to correctly identify
the new device file.

[1]
INFO: task syz-executor:5986 blocked for more than 143 seconds.
Call Trace:
 fuse_chan_wait_aborted+0x15b/0x250 fs/fuse/dev.c:2212
 fuse_conn_destroy+0x1e7/0x3e0 fs/fuse/inode.c:1969
 fuse_sb_destroy fs/fuse/inode.c:1988 [inline]
 fuse_kill_sb_anon+0x1ef/0x270 fs/fuse/inode.c:2001
 deactivate_locked_super+0xbc/0x130 fs/super.c:476
 cleanup_mnt+0x437/0x4d0 fs/namespace.c:1312

Fixes: 88bf1f670f99 ("fuse: simplify fuse_dev_ioctl_clone()")
Reported-by: syzbot+eede1fb91fb15bbbd5f2@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=eede1fb91fb15bbbd5f2
Tested-by: syzbot+eede1fb91fb15bbbd5f2@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/fuse/dev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 25c5c853a791..7c130656c4f6 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -2291,6 +2291,9 @@ static long fuse_dev_ioctl_clone(struct file *file, __u32 __user *argp)
 		return -ENOMEM;
 
 	new_fud = fuse_file_to_fud(file);
+	if (fuse_dev_chan_get(new_fud))
+		return -EINVAL;
+
 	if (!fuse_dev_install_with_pq(new_fud, fud->chan, pq))
 		return -EINVAL;
 
-- 
2.43.0

On Sun, 19 Apr 2026 at 07:27, Edward Adam Davis <eadavis@qq.com> wrote:
>
> In fuse_dev_install_with_pq(), after updating the chan for the new device,
> the fch->connected value for the old device is set to 0. This logic is
> fundamentally flawed in cases where the new fd passed during a clone
> operation is identical to the device file's fd; specifically, during
> an unmount operation, this prevents fuse_conn_destroy() and subsequently
> fuse_chan_abort() from terminating pending requests, and the wake-up of
> the blocked_waitq is also consequently skipped. This triggers a timeout
> in fuse_chan_wait_aborted() [1].
>
> The original conditional logic has been restored to correctly identify
> the new device file.

Thanks for the patch.  I fixed it differently in #for-next:

    Move aborting the connection (setting fc->connected to zero) to
    fuse_dev_install(), because it is not needed when the clone ioctl fails.

Thanks,
Miklos