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

***

Subject: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()
Author: kartikey406@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+b74150fd2ef40e716ca2@syzkaller.appspot.com
Closes: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
Signed-off-by: Deepanshu Kartikey <kartikey406@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

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?

On Sun, Nov 30, 2025 at 07:30:17AM +0000, Al Viro wrote:
> 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?

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

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 <brauner@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 <brauner@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 <brauner@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 <brauner@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 <christian@brauner.io>" [ultimate]
    # gpg:                 aka "Christian Brauner <christian.brauner@getenv.org>" [ultimate]
    # gpg:                 aka "Christian Brauner <brauner@kernel.org>" [ultimate]
    
    # Conflicts:
    #       include/linux/cleanup.h
    #       ipc/mqueue.c

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