linux-kernel - Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <176457944867.16766.7275624308956648849@noble.neil.brown.name>
Date: Mon, 01 Dec 2025 19:57:28 +1100
From: NeilBrown <neilb@...mail.net>
To: "Amir Goldstein" <amir73il@...il.com>
Cc: "Deepanshu Kartikey" <kartikey406@...il.com>, brauner@...nel.org,
 viro@...iv.linux.org.uk, jlayton@...nel.org, linux-kernel@...r.kernel.org,
 syzbot+b74150fd2ef40e716ca2@...kaller.appspot.com
Subject:
 Re: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open()

On Mon, 01 Dec 2025, Amir Goldstein wrote:
> On Sun, Nov 30, 2025 at 11:27 PM NeilBrown <neilb@...mail.net> wrote:
> >
> > On Sun, 30 Nov 2025, Amir Goldstein wrote:
> > > On Sun, Nov 30, 2025 at 10:27 AM Deepanshu Kartikey
> > > <kartikey406@...il.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