linux-kernel - Re: Forwarded: [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: <20251130084612.GT3538@ZenIV>
Date: Sun, 30 Nov 2025 08:46:12 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: syzbot <syzbot+b74150fd2ef40e716ca2@...kaller.appspotmail.com>
Cc: linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
	Christian Brauner <christian@...uner.io>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: Forwarded: [PATCH] ipc/mqueue: fix dentry refcount imbalance in
 prepare_open()

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