[syzbot] [overlayfs?] WARNING in fast_dput

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 7d31f578f323 Add linux-next specific files for 20251128
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14db5f42580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
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=1780a112580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f6be92580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6b49d8ad90de/disk-7d31f578.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dbe2d4988ca7/vmlinux-7d31f578.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fc0448ab2411/bzImage-7d31f578.xz

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

------------[ cut here ]------------
WARNING: fs/dcache.c:829 at fast_dput+0x334/0x430 fs/dcache.c:829, CPU#1: syz.0.17/6053
Modules linked in:
CPU: 1 UID: 0 PID: 6053 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:fast_dput+0x334/0x430 fs/dcache.c:829
Code: e3 81 ff 48 b8 00 00 00 00 00 fc ff df 41 0f b6 44 05 00 84 c0 0f 85 e2 00 00 00 41 80 0e 40 e9 fd fe ff ff e8 4d e3 81 ff 90 <0f> 0b 90 e9 ef fe ff ff 44 89 e6 81 e6 00 00 04 00 31 ff e8 74 e7
RSP: 0018:ffffc90003407cd8 EFLAGS: 00010293
RAX: ffffffff823fcfe3 RBX: ffff88806c44ac78 RCX: ffff88802e41bd00
RDX: 0000000000000000 RSI: 00000000ffffff80 RDI: 0000000000000001
RBP: 00000000ffffff80 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000680f8c R12: dffffc0000000000
R13: 1ffff1100d889597 R14: ffff88806c44abc0 R15: ffff88806c44acb8
FS: 00005555820e4500(0000) GS:ffff888125f4f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31b63fff CR3: 0000000072c78000 CR4: 00000000003526f0
Call Trace:
<TASK>
dput+0xe8/0x1a0 fs/dcache.c:924
__fput+0x68e/0xa70 fs/file_table.c:476
task_work_run+0x1d4/0x260 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:44 [inline]
exit_to_user_mode_loop+0xff/0x4f0 kernel/entry/common.c:75
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
do_syscall_64+0x2e3/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4966f8f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc01c51258 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 000000000001a7a1 RCX: 00007f4966f8f749
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000201c5154f
R10: 0000001b30f20000 R11: 0000000000000246 R12: 00007f49671e5fac
R13: 00007f49671e5fa0 R14: ffffffffffffffff R15: 0000000000000004
</TASK>


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

[Hillf Danton]

> Date: Sat, 29 Nov 2025 05:05:23 -0800 [thread overview]

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 7d31f578f323 Add linux-next specific files for 20251128
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14db5f42580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
> dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
> 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=1780a112580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f6be92580000

#syz test

--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -1224,9 +1224,9 @@ int ovl_lock_rename_workdir(struct dentr
goto err;
if (trap)
goto err_unlock;
- if (work && work->d_parent != workdir)
+ if (work && (work->d_parent != workdir || d_unhashed(work)))
goto err_unlock;
- if (upper && upper->d_parent != upperdir)
+ if (upper && (upper->d_parent != upperdir || d_unhashed(work)))
goto err_unlock;

return 0;
--

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in fast_dput

------------[ cut here ]------------
WARNING: fs/dcache.c:829 at fast_dput+0x334/0x430 fs/dcache.c:829, CPU#1: syz.0.17/6545
Modules linked in:
CPU: 1 UID: 0 PID: 6545 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:fast_dput+0x334/0x430 fs/dcache.c:829
Code: e3 81 ff 48 b8 00 00 00 00 00 fc ff df 41 0f b6 44 05 00 84 c0 0f 85 e2 00 00 00 41 80 0e 40 e9 fd fe ff ff e8 4d e3 81 ff 90 <0f> 0b 90 e9 ef fe ff ff 44 89 e6 81 e6 00 00 04 00 31 ff e8 74 e7

RSP: 0018:ffffc90003147cd8 EFLAGS: 00010293
RAX: ffffffff823fcfe3 RBX: ffff88805c212988 RCX: ffff8880779bbd00

RDX: 0000000000000000 RSI: 00000000ffffff80 RDI: 0000000000000001
RBP: 00000000ffffff80 R08: 0000000000000003 R09: 0000000000000004

R10: dffffc0000000000 R11: fffff52000628f8c R12: dffffc0000000000
R13: 1ffff1100b842539 R14: ffff88805c2128d0 R15: ffff88805c2129c8
FS: 000055558468e500(0000) GS:ffff888125f4f000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000001b30763fff CR3: 000000007d39a000 CR4: 00000000003526f0

Call Trace:
<TASK>
dput+0xe8/0x1a0 fs/dcache.c:924
__fput+0x68e/0xa70 fs/file_table.c:476
task_work_run+0x1d4/0x260 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:44 [inline]
exit_to_user_mode_loop+0xff/0x4f0 kernel/entry/common.c:75
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
do_syscall_64+0x2e3/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7fb34398f749

Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007ffd90d758e8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 0000000000021fa6 RCX: 00007fb34398f749

RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003

RBP: 00007fb343be7da0 R08: 0000000000000001 R09: 0000000290d75bdf
R10: 0000001b2fb20000 R11: 0000000000000246 R12: 00007fb343be5fac
R13: 00007fb343be5fa0 R14: ffffffffffffffff R15: 00007ffd90d75a00
</TASK>


Tested on:

commit: 7d31f578 Add linux-next specific files for 20251128
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12b430c2580000

kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=144dfe92580000

[syzbot]

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

***

Subject: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()
Author: karti...@gmail.com

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

When opening an existing message queue, prepare_open() does not increment
the dentry refcount, but end_creating() always calls dput(). This causes
a refcount imbalance that triggers a WARN_ON_ONCE in fast_dput() when the
file is later closed.

The creation path via vfs_mkobj() correctly increments the refcount, but
the "already exists" path was missing the corresponding dget().

Add the missing dget() call when opening an existing queue to balance the
dput() in end_creating().

Reported-by: syzbot+b74150...@syzkaller.appspot.com
Closes: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
ipc/mqueue.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 328bcc3ee3ad..63ff2c322549 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -883,6 +883,7 @@ static int prepare_open(struct dentry *dentry, int oflag, int ro,
if ((oflag & O_ACCMODE) == (O_RDWR | O_WRONLY))
return -EINVAL;
acc = oflag2acc[oflag & O_ACCMODE];
+ dget(dentry);
return inode_permission(&nop_mnt_idmap, d_inode(dentry), acc);
}

--
2.43.0

[Al Viro]

On Sat, Nov 29, 2025 at 11:11:24PM -0800, syzbot wrote:

> When opening an existing message queue, prepare_open() does not increment
> the dentry refcount, but end_creating() always calls dput(). This causes
> a refcount imbalance that triggers a WARN_ON_ONCE in fast_dput() when the
> file is later closed.

That makes no sense.

> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -883,6 +883,7 @@ static int prepare_open(struct dentry *dentry, int oflag, int ro,
> if ((oflag & O_ACCMODE) == (O_RDWR | O_WRONLY))
> return -EINVAL;

... we return an error without refcount increment.

> acc = oflag2acc[oflag & O_ACCMODE];
> + dget(dentry);
> return inode_permission(&nop_mnt_idmap, d_inode(dentry), acc);

... with possibly return an error *with* refcount increment.
How the caller is supposed to tell one from another?

[Al Viro]

Mismerge in -next, actually.

static struct file *mqueue_file_open(struct filename *name,
struct vfsmount *mnt, int oflag, bool ro,
umode_t mode, struct mq_attr *attr)
{
struct path path __free(path_put) = {};
struct dentry *dentry;
struct file *file;
int ret;

dentry = start_creating_noperm(mnt->mnt_root, &QSTR(name->name));
if (IS_ERR(dentry))
return ERR_CAST(dentry);

path.dentry = dentry;
path.mnt = mntget(mnt);

ret = prepare_open(path.dentry, oflag, ro, mode, name, attr);
if (ret)
return ERR_PTR(ret);
This leaves with parent still locked

file = dentry_open(&path, oflag, current_cred());
end_creating(dentry);
return file;
... and this does double-dput, somewhat masked by the fact that in
"new file" case dentry had its refcount bumped to pin it down.

Folks, RAII is a dangerous thing, especially around source manipulations,
merging very much included...

[syzbot]

Hello,

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

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

Tested on:

commit: 7d31f578 Add linux-next specific files for 20251128
git tree: linux-next

console output: https://syzkaller.appspot.com/x/log.txt?x=14231112580000

kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=13ab3912580000

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

[Al Viro]

On Sun, Nov 30, 2025 at 08:46:12AM +0000, Al Viro wrote:

> Mismerge in -next, actually.

... in vfs.all, fixed there since then.

commit 73612a36da1a09df19e205c6c6fd8a22ed441716
Merge: 6fda44ca8203 def1b1ed02b8
Author: Christian Brauner <bra...@kernel.org>
Date: Thu Nov 27 11:56:07 2025 +0100

Merge branch 'vfs-6.19.fd_prepare' into vfs.all

Signed-off-by: Christian Brauner <bra...@kernel.org>

# Conflicts:
# include/linux/cleanup.h
# ipc/mqueue.c

is where it happened and it's what -next has pulled.

Currently it's replaced with
commit d6ea5537c1a66a54d34f50d51ad201b1a2319ccf (vfs-common/vfs.all)
Merge: 80019251fa80 65c2c221846e
Author: Christian Brauner <bra...@kernel.org>
Date: Fri Nov 28 17:32:43 2025 +0100

Merge tag 'vfs-6.19-rc1.fd_prepare' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs into vfs.all

vfs-6.19-rc1.fd_prepare

Signed-off-by: Christian Brauner <bra...@kernel.org>

# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCaSmOZwAKCRCRxhvAZXjc
# ouPcAQCFC+L9+ATyKDUpJj/7CS9PbHR9eSnBnwRfgafWY1wl5gD/c/0S7g6f7WTL
# nZwIMoQCAcUJDQpPlAcfNbUXKkwgWAA=
# =K19o
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 28 Nov 2025 12:58:31 CET
# gpg: using EDDSA key 408734571EA70C78B332692891C61BC06578DCA2
# gpg: Good signature from "Christian Brauner <chri...@brauner.io>" [ultimate]
# gpg: aka "Christian Brauner <christia...@getenv.org>" [ultimate]
# gpg: aka "Christian Brauner <bra...@kernel.org>" [ultimate]

# Conflicts:
# include/linux/cleanup.h
# ipc/mqueue.c

in there, and -next simply hasn't picked it yet.

[Hillf Danton]

> Date: Sat, 29 Nov 2025 05:05:23 -0800 [thread overview]

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 7d31f578f323 Add linux-next specific files for 20251128
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14db5f42580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
> dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
> 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=1780a112580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f6be92580000

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all

[syzbot]

Hello,

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

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

Tested on:

commit: d6ea5537 Merge tag 'vfs-6.19-rc1.fd_prepare' of gitoli..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all
console output: https://syzkaller.appspot.com/x/log.txt?x=16218512580000
kernel config: https://syzkaller.appspot.com/x/.config?x=859bdb453c94e06c

dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Note: no patches were applied.

[Amir Goldstein]

Any idea why this was tagged as overlayfs?
I do not see overlayfs anywhere in the repro, logs, or stack trace.

Neil thinks this might be already fixed upstream, but
given the recency of this report, I doubt it.

#syz test upstream master

Thanks,
Amir.

[Al Viro]

Sigh... It's not in mainline at all. It's in vfs/vfs.git #vfs.all,
and yes, it had been fixed there as of
commit d6ea5537c1a66a54d34f50d51ad201b1a2319ccf

Merge: 80019251fa80 65c2c221846e
Author: Christian Brauner <bra...@kernel.org>
Date: Fri Nov 28 17:32:43 2025 +0100

Merge tag 'vfs-6.19-rc1.fd_prepare' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs into vfs.all

Wait for Monday, hopefully -next will pick it...

[Aleksandr Nogikh]

Looks like the crash title is too generic, so we ended up with a
collection of unrelated crashes here. However, several issues are
indeed related to overlayfs:
https://syzkaller.appspot.com/text?tag=CrashReport&x=143464b4580000
https://syzkaller.appspot.com/text?tag=CrashReport&x=1683a112580000

[syzbot]

Hello,

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

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

Tested on:

commit: 7d0a66e4 Linux 6.18
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10b5c192580000
kernel config: https://syzkaller.appspot.com/x/.config?x=859bdb453c94e06c

dashboard link: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

[Amir Goldstein]

OK but which repo, if any, are those crashes related to?
I am not exactly sure how to process this information.

Thanks,
Amir.

[Aleksandr Nogikh]

See the crashes at "2025/11/28 23:23" and at "2025/11/29 06:18" at the
bottom of the page here:
https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2

Both were found on next-20251128.

>
> Thanks,
> Amir.

[Amir Goldstein]

I see.
I'll take Al's word for it, that these are all related to the same merge issue
in the point in time next-20251128
that will be fixed in the next linux-next tag.

Thanks,
Amir.