From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.170]) (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 1EF7044BCA5 for ; Tue, 5 May 2026 14:44:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.121.94.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777992247; cv=none; b=ZEqxvDLIZr2XjHrmsJWWYT6de5wsubE1Ue+bqRS+DZUOsu8z6J5nMjNbAnBYIovYN6dqn6TrmZ7HWHu3wBV5TPzDtQmrp87nsE4PaNRQR6E+HXjYcQFIY97fJ1fOF+jXxZpPdFRwigRXzxRrpFeDW+eupI8M0QA8BaIP/I59qKs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777992247; c=relaxed/simple; bh=sJ1FkjPsRbzQizJUznEHuhNPDw227vUNlg5aTigQ4Dk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iXKmTvvfnw4Y42YO4lXzfTN26IFMpMlX05fzkzLXlwQitlWlqNu9IW/dIq6RblYAeiBFlyPGVJ6dE/yWy3iJmq8CgWRxQWCckcG3L7C1v0wr2sxYmgZxdBgCsJWJ0OwTdmFFAjc2JN1f7hyCD/qWe4pk02zF/1VcFe+Sh5YtLek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=xs4all.nl; spf=pass smtp.mailfrom=xs4all.nl; dkim=pass (2048-bit key) header.d=xs4all.nl header.i=@xs4all.nl header.b=bbeZRZlH; arc=none smtp.client-ip=195.121.94.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=xs4all.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=xs4all.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=xs4all.nl header.i=@xs4all.nl header.b="bbeZRZlH" X-KPN-MessageId: d819d003-4890-11f1-8a9e-005056ab378f Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id d819d003-4890-11f1-8a9e-005056ab378f; Tue, 05 May 2026 16:43:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=content-type:mime-version:message-id:subject:to:from:date; bh=EpkfHYDX9N36ztJc2XbQY5BO+uE0H/CU/VDcE+8AHjA=; b=bbeZRZlH99trB392SOY3R65FM+yETtrWK9Bxv0XI+ZpxkHWXJHHWhVPkGtEtnADkbkTkJhdjL3K7t HqKAP4wO8Dfas5AWXADInIeWrVSPtTeOl0HjSdHEpBHTp6FCBCI0zV+3Zbu7/b/uIthUXHqRRaDdoI FlCI8k3nt8fH12nMO5z7McW2ONtE/4E5GaLF6aTKoOJY2SYJRqnWIdzQn/YGeEETflbjs83MhiqZfc xLkqC+F1n9e9/LuGuRSt6FqBSQHod2IxNyqql2uPtNLAKR2bVnwtYHHXUxG3tf2rAAsaSvwZQCITPf HqJEJCBEx3I3GLdvQ2D9PaZzeYMgqzA== X-KPN-MID: 33|Jq0cOGL0rjqmzvd1bcL7OgQl73bPb2TM0tWIB9TK65o4xDg+LtDc0s9qo4fBlse CBKGset0WhPuJvhf1b4oqnX/wT4ULDNX1yZbCXOsnhVA= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|zbVZQVf1Cv6U+B29KN7YnrXIyD6146KtqzupM40dCiizNeYwv6+yB8IFc8Uf4m8 iOq4dvERLLlWUdAcsJimRyQ== Received: from localhost (unknown [178.226.144.191]) by smtp.xs4all.nl (Halon) with ESMTPSA id d7d3101a-4890-11f1-a6cc-005056abf0db; Tue, 05 May 2026 16:43:56 +0200 (CEST) Date: Tue, 5 May 2026 16:43:48 +0200 From: Jori Koolstra To: Vineet Agarwal Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot Subject: Re: [PATCH] fs/namespace: fix NULL pointer dereference in do_lock_mount() Message-ID: Mail-Followup-To: Jori Koolstra , Vineet Agarwal , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot References: <20260505095156.178351-1-agarwal.vineet2006@gmail.com> 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: <20260505095156.178351-1-agarwal.vineet2006@gmail.com> On Tue, May 05, 2026 at 03:21:31PM +0530, Vineet Agarwal wrote: > Syzkaller reported a NULL pointer dereference in do_lock_mount() > when calling inode_lock() on a dentry without an associated inode. > > where_to_mount() may return a negative dentry (without an inode) > due to concurrent unlink or mount changes. The current code does > not validate this before calling inode_lock(), leading to a crash. Can you explain what call path could lead to having path here refer to a negative dentry? Is it not the case that a positive dentry's d_inode is stable as long as you hold a reference to the dentry? If, so it cannot be killed underneath us. > > Fix this by checking dentry and dentry->d_inode before acquiring > the inode lock. > > Reported-by: syzbot This is not enough. Which syzbot issue are you trying to fix? > Closes: https://syzkaller.appspot.com/ > Signed-off-by: Vineet Agarwal > --- > fs/namespace.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/fs/namespace.c b/fs/namespace.c > index fe919abd2f01..b1dccdf06836 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -2760,6 +2760,17 @@ static void do_lock_mount(const struct path *path, > } > } > > + if (unlikely(!dentry || !dentry->d_inode)) { > + err = -ENOENT; > + if (&m->mnt != path->mnt) { > + if (dentry) > + dput(dentry); > + mntput(&m->mnt); > + } > + res->parent = ERR_PTR(err); > + return; > + } > + > inode_lock(dentry->d_inode); > namespace_lock(); > > -- > 2.54.0 > Thanks, Jori.