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

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

[Deepanshu Kartikey]

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: syzbot+344c09c64fcd8d3d2782@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=344c09c64fcd8d3d2782
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 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

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

[Deepanshu Kartikey]

On Sat, Jul 25, 2026 at 7:14 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> 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: syzbot+344c09c64fcd8d3d2782@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=344c09c64fcd8d3d2782
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  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
>

Gentle Reminder. Let me know anythng else needed from my side.

Thanks

Deepanshu

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

[Deepanshu Kartikey]

On Sat, Jul 25, 2026 at 7:14 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> 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: syzbot+344c09c64fcd8d3d2782@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=344c09c64fcd8d3d2782
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  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
>

Gentle Reminder. Let me know anythng else needed from my side.

Thanks

Deepanshu

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

[Dominique Martinet]

Deepanshu Kartikey wrote on Sat, Jul 25, 2026 at 07:14:48AM +0530:
> 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: syzbot+344c09c64fcd8d3d2782@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=344c09c64fcd8d3d2782
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>

Fair enough, picked up for 7.4
-- 
Dominique Martinet | Asmadeus