[PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[Deepanshu Kartikey]

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

Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[Amir Goldstein]

On Sun, Nov 30, 2025 at 10:27 AM Deepanshu Kartikey
<kartikey406@gmail.com> 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.
>
> 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().

Sorry but this analysis looks wrong.

AFAIS, the bug was that end_creating() should have been before the out_putfd
label just as path_put() was before the commit.

>
> Reported-by: syzbot+b74150fd2ef40e716ca2@syzkaller.appspot.com
> Closes: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2

Fix should have
Fixes: c9ba789dad15b ("VFS: introduce start_creating_noperm() and
start_removing_noperm()")

But I see this is already fixed by the FD_ADD() work and  mqueue_file_open()
helper by Christian.

Specifically, the bug was fixed by the merge conflict resolution
d6ea5537c1a66 Merge tag 'vfs-6.19-rc1.fd_prepare' of
gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs into vfs.all

Which should be in linux-next from yesterday.

Christian,

Do you think we need a fix mid-way before the merge of FD_ADD()?

Thanks,
Amir.

Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[NeilBrown]

On Sun, 30 Nov 2025, Amir Goldstein wrote:
> On Sun, Nov 30, 2025 at 10:27 AM Deepanshu Kartikey
> <kartikey406@gmail.com> 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.
> >
> > 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().
> 
> Sorry but this analysis looks wrong.

Agreed.  vfs_mkobj() takes a ref (via mqueue_create_attr) on a newly
created dentry to keep it in dcache.  The open-existing path doesn't
need to do that.

> 
> AFAIS, the bug was that end_creating() should have been before the out_putfd
> label just as path_put() was before the commit.

Disagree.  Moving end_creating() earlier to before out_putfd: would only
affect code paths that "goto out_putfd".  The only code that does that
in when path.dentry is an IS_ERR() so there is nothing to dput.

I don't think there is a bug here.  The dput() issue in the syzkaller
report below has already been addressed by an overlayfs fix in
ovl_lock_rename_workdir().

Thanks,
NeilBrown

> 
> >
> > Reported-by: syzbot+b74150fd2ef40e716ca2@syzkaller.appspot.com
> > Closes: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2
> 
> Fix should have
> Fixes: c9ba789dad15b ("VFS: introduce start_creating_noperm() and
> start_removing_noperm()")
> 
> But I see this is already fixed by the FD_ADD() work and  mqueue_file_open()
> helper by Christian.
> 
> Specifically, the bug was fixed by the merge conflict resolution
> d6ea5537c1a66 Merge tag 'vfs-6.19-rc1.fd_prepare' of
> gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs into vfs.all
> 
> Which should be in linux-next from yesterday.
> 
> Christian,
> 
> Do you think we need a fix mid-way before the merge of FD_ADD()?
> 
> Thanks,
> Amir.
> 

Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[Amir Goldstein]

On Sun, Nov 30, 2025 at 11:27 PM NeilBrown <neilb@ownmail.net> wrote:
>
> On Sun, 30 Nov 2025, Amir Goldstein wrote:
> > On Sun, Nov 30, 2025 at 10:27 AM Deepanshu Kartikey
> > <kartikey406@gmail.com> 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.
> > >
> > > 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().
> >
> > Sorry but this analysis looks wrong.
>
> Agreed.  vfs_mkobj() takes a ref (via mqueue_create_attr) on a newly
> created dentry to keep it in dcache.  The open-existing path doesn't
> need to do that.
>
> >
> > AFAIS, the bug was that end_creating() should have been before the out_putfd
> > label just as path_put() was before the commit.
>
> Disagree.  Moving end_creating() earlier to before out_putfd: would only
> affect code paths that "goto out_putfd".  The only code that does that
> in when path.dentry is an IS_ERR() so there is nothing to dput.
>
> I don't think there is a bug here.  The dput() issue in the syzkaller
> report below has already been addressed by an overlayfs fix in
> ovl_lock_rename_workdir().
>

Maybe so, but the syzbot repro has nothing to do with overlayfs
I have absolutely no idea why the bot tagged this report as [overlayfs]
but I will ask it to retest on upstream.

Thanks,
Amir.

Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[NeilBrown]

On Mon, 01 Dec 2025, Amir Goldstein wrote:
> On Sun, Nov 30, 2025 at 11:27 PM NeilBrown <neilb@ownmail.net> wrote:
> >
> > On Sun, 30 Nov 2025, Amir Goldstein wrote:
> > > On Sun, Nov 30, 2025 at 10:27 AM Deepanshu Kartikey
> > > <kartikey406@gmail.com> 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.
> > > >
> > > > 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().
> > >
> > > Sorry but this analysis looks wrong.
> >
> > Agreed.  vfs_mkobj() takes a ref (via mqueue_create_attr) on a newly
> > created dentry to keep it in dcache.  The open-existing path doesn't
> > need to do that.
> >
> > >
> > > AFAIS, the bug was that end_creating() should have been before the out_putfd
> > > label just as path_put() was before the commit.
> >
> > Disagree.  Moving end_creating() earlier to before out_putfd: would only
> > affect code paths that "goto out_putfd".  The only code that does that
> > in when path.dentry is an IS_ERR() so there is nothing to dput.
> >
> > I don't think there is a bug here.  The dput() issue in the syzkaller
> > report below has already been addressed by an overlayfs fix in
> > ovl_lock_rename_workdir().
> >
> 
> Maybe so, but the syzbot repro has nothing to do with overlayfs
> I have absolutely no idea why the bot tagged this report as [overlayfs]
> but I will ask it to retest on upstream.
> 
> Thanks,
> Amir.
> 

The patch we are replying to contained

Closes: https://syzkaller.appspot.com/bug?extid=b74150fd2ef40e716ca2

That page says 
   Subsystems: overlayfs
and 

Status: upstream: reported C repro on 2025/11/29 13:05
which is a link to
  https://groups.google.com/g/syzkaller-bugs/c/rcOfN4hdoHw/m/pw0jTqSiCAAJ

which I misread as mentioning my recent ovl patch as a fix, but it
doesn't.

Al says it was a mismerge in -next, which has been resolved.

https://lore.kernel.org/all/20251130084612.GT3538@ZenIV

Sorry for blaming ovl :-)

NeilBrown

Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

[Al Viro]

On Mon, Dec 01, 2025 at 07:57:28PM +1100, NeilBrown wrote:

> Al says it was a mismerge in -next, which has been resolved.

In vfs-common/vfs.all, actually, and it had been resolved there,
too late for the last -next of the week...