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: <176454167053.634289.7042945216095806518@noble.neil.brown.name>
Date: Mon, 01 Dec 2025 09:27:50 +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 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().

Thanks,
NeilBrown

> 
> >
> > Reported-by: syzbot+b74150fd2ef40e716ca2@...kaller.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.
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ