[PATCH] 9p: don't WARN_ONCE on racy symlink fid lookup failure

Deepanshu Kartikey <[email protected]> Sat, 25 Jul 2026 07:14:48 +0530
Newsgroups dev.linux.lists.v9fs,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
v9fs_init_request() WARN_ONCE()s when v9fs_fid_lookup() fails for a
symlink read via the page cache. This is a benign TOCTOU race: a
concurrent unlink()/rename() can remove the target between the walk
finding the dentry and p9_client_walk() completing, so the lookup
legitimately fails with -ENOENT (observed: dentry=/file0, err=-2).

With panic_on_warn=1, this WARN escalates to a full kernel panic --
an unprivileged local DoS reachable by racing mount() against a
concurrent unlink/rename.

Return the error directly instead of WARN_ONCE().

Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=344c09c64fcd8d3d2782
Signed-off-by: Deepanshu Kartikey <[email protected]>
---
 fs/9p/vfs_addr.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index 1ac0b3dcc077..121679488ab9 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -140,13 +140,16 @@ static int v9fs_init_request(struct netfs_io_request *rreq, struct file *file)
 			goto no_fid;
 		p9_fid_get(fid);
 	} else if (S_ISLNK(rreq->inode->i_mode)) {
+		/* racing unlink/rename can make this fail with -ENOENT;
+		 * that's expected, not a kernel bug, so don't WARN
+		 */
 		dentry = d_find_any_alias(rreq->inode);
 		if (!dentry)
 			goto no_fid;
 		fid = v9fs_fid_lookup(dentry);
 		dput(dentry);
 		if (IS_ERR(fid))
-			goto no_fid;
+			return PTR_ERR(fid);
 	} else {
 		fid = v9fs_fid_find_inode(rreq->inode, writing, INVALID_UID, true);
 		if (!fid)
-- 
2.43.0