From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A47B11CAF for ; Sun, 30 Nov 2025 08:46:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764492369; cv=none; b=gJnLL/f6o3VhvqjVU1PlZhkPXYtyUB1h0yLZvLOjj4kF3YwNnG3vivFn31WrkLCQfTUXaPqfJI9K2ApuYICd/srOe9gleg/63iQFBHteZboQGeJHqUh6z4dL1/XzcJYDS2dcNntyupW2DXMkwqI7kKQzdZPQbAyrNk0iDPg2gf0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764492369; c=relaxed/simple; bh=8wSVsUVtJy4ENicDmo5yU8V3zqRb+Ig/gyCC6KR1SlI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Orl6TxIbEVwGAjjNFjKXlMq0Oq2mJ/2+5eO/bfamGNCicDDOMMiYo6YLZVCmXdVDp9VNyKAPTB1MntkkFuU+nVIEkSJ0QzbLPz4L3w9rnir7DEvA41dP8lgYl7Zq4i0jdW802ruUH3ZhD7xMshHRIP5zpq1tOaSD9Z8zQsFPYQY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=slar1HdE; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="slar1HdE" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=nLkTOePryLh/4MoC334r7+tZdonazSw1nduiVpn6Iic=; b=slar1HdE7ODIewHZycT7qnEiyH gnLTB6nB33/tC0UU3JQYl/O31rW8XUKnfbAR+uZni+GZ3ki7JISdadm2ntYszWTeNRsibvQoVEMck zhv9cSUAeU12QUkMP7REoZrZLETfZhd5R/sv1EfjApdTfTY9w8FGFkIRThYXBolTwD2zbaIhN+IAd T5XBTIxh0Zva6xh9Kf+979X0cJ59MR+kqemjpSSCKmqIrzh3cmOsuOJTrgtAvgD2GhBPIvqB8pCRh CDcFCaP0fVQz8zFPSB8DAsp1Kv+AdNOc8tjEZg8pxZY5xJgnelZDZsH9EK+45uV3ApobWy9/Wr65C PCyz1B/A==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1vPd4O-00000001KzB-2UfO; Sun, 30 Nov 2025 08:46:12 +0000 Date: Sun, 30 Nov 2025 08:46:12 +0000 From: Al Viro To: syzbot Cc: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, Christian Brauner , Stephen Rothwell Subject: Re: Forwarded: [PATCH] ipc/mqueue: fix dentry refcount imbalance in prepare_open() Message-ID: <20251130084612.GT3538@ZenIV> References: <692aef93.a70a0220.d98e3.015b.GAE@google.com> <692bee1c.a70a0220.d98e3.0167.GAE@google.com> <20251130073017.GS3538@ZenIV> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251130073017.GS3538@ZenIV> Sender: Al Viro 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...