Re: [PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

Re: [PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Deepanshu Kartikey]

Hi,

I wanted to follow up on the v2 patch addressing the nsfs file handle 
validation issue. Jan Kara has provided his Reviewed-by, and Christian 
mentioned plans for future changes with the unified nstree work.

Could you please let me know the status of this patch? Is there anything 
else needed from my side for it to be considered for merging?

Thanks for your time and feedback.

Best regards,
Deepanshu

Re: [PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Christian Brauner]

On Sat, Oct 04, 2025 at 07:04:52AM +0530, Deepanshu Kartikey wrote:
> Hi,
> 
> I wanted to follow up on the v2 patch addressing the nsfs file handle 
> validation issue. Jan Kara has provided his Reviewed-by, and Christian 
> mentioned plans for future changes with the unified nstree work.
> 
> Could you please let me know the status of this patch? Is there anything 
> else needed from my side for it to be considered for merging?
> 
> Thanks for your time and feedback.

It's in the vfs.fixes tree and will go out with the first set of fixes
for this cycle.

Re: [PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Christian Brauner]

On Wed, Sep 24, 2025 at 05:20:58PM +0530, Deepanshu Kartikey wrote:
> Replace VFS_WARN_ON_ONCE() with graceful error handling when file
> handles contain inode numbers that don't match the actual namespace
> inode. This prevents userspace from triggering kernel warnings by
> providing malformed file handles to open_by_handle_at().
> 
> The issue occurs when userspace provides a file handle with valid
> namespace type and ID that successfully locates a namespace, but
> specifies an incorrect inode number. Previously, this would trigger
> VFS_WARN_ON_ONCE() when comparing the real inode number against the
> provided value.
> 
> Since file handle data is user-controllable, inode number mismatches
> should be treated as invalid input rather than kernel consistency
> errors. Handle this case by returning NULL to indicate the file
> handle is invalid, rather than warning about what is essentially
> user input validation.
> 
> Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
> Suggested-by: Jan Kara <jack@suse.cz>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  fs/nsfs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Changes in v2:
> - Handle all inode number mismatches, not just zero, as suggested by Jan Kara
> - Replace warning with graceful error handling for better architecture
> 
> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 32cb8c835a2b..002d424d9fa6 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -490,8 +490,9 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
>  
>  		VFS_WARN_ON_ONCE(ns->ns_id != fid->ns_id);
>  		VFS_WARN_ON_ONCE(ns->ops->type != fid->ns_type);
> -		VFS_WARN_ON_ONCE(ns->inum != fid->ns_inum);
> -
> +		/* Someone is playing games and passing invalid file handles? */
> +		if (ns->inum != fid->ns_inum)
> +			return NULL;
>  		if (!refcount_inc_not_zero(&ns->count))
>  			return NULL;
>  	}
> -- 
> 2.43.0
> 

That seems sane although I have considered to relax the decoding part in
the future. IOW, the kernel must always return the file handle with all
fields filled in. But userspace may be allowed to specify just the
->ns_id and leave both ->inum and ->ns_type zero. This is based on a
patch for next cycled "unified nstree". Anyway, thanks for the fix.

[PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Deepanshu Kartikey]

Replace VFS_WARN_ON_ONCE() with graceful error handling when file
handles contain inode numbers that don't match the actual namespace
inode. This prevents userspace from triggering kernel warnings by
providing malformed file handles to open_by_handle_at().

The issue occurs when userspace provides a file handle with valid
namespace type and ID that successfully locates a namespace, but
specifies an incorrect inode number. Previously, this would trigger
VFS_WARN_ON_ONCE() when comparing the real inode number against the
provided value.

Since file handle data is user-controllable, inode number mismatches
should be treated as invalid input rather than kernel consistency
errors. Handle this case by returning NULL to indicate the file
handle is invalid, rather than warning about what is essentially
user input validation.

Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/nsfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Changes in v2:
- Handle all inode number mismatches, not just zero, as suggested by Jan Kara
- Replace warning with graceful error handling for better architecture

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 32cb8c835a2b..002d424d9fa6 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -490,8 +490,9 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
 
 		VFS_WARN_ON_ONCE(ns->ns_id != fid->ns_id);
 		VFS_WARN_ON_ONCE(ns->ops->type != fid->ns_type);
-		VFS_WARN_ON_ONCE(ns->inum != fid->ns_inum);
-
+		/* Someone is playing games and passing invalid file handles? */
+		if (ns->inum != fid->ns_inum)
+			return NULL;
 		if (!refcount_inc_not_zero(&ns->count))
 			return NULL;
 	}
-- 
2.43.0

Re: [PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Jan Kara]

On Wed 24-09-25 17:07:45, Deepanshu Kartikey wrote:
> Replace VFS_WARN_ON_ONCE() with graceful error handling when file
> handles contain inode numbers that don't match the actual namespace
> inode. This prevents userspace from triggering kernel warnings by
> providing malformed file handles to open_by_handle_at().
> 
> The issue occurs when userspace provides a file handle with valid
> namespace type and ID that successfully locates a namespace, but
> specifies an incorrect inode number. Previously, this would trigger
> VFS_WARN_ON_ONCE() when comparing the real inode number against the
> provided value.
> 
> Since file handle data is user-controllable, inode number mismatches
> should be treated as invalid input rather than kernel consistency
> errors. Handle this case by returning NULL to indicate the file
> handle is invalid, rather than warning about what is essentially
> user input validation.
> 
> Changes in v2:
> - Handle all inode number mismatches, not just zero, as suggested by Jan Kara
> - Replace warning with graceful error handling for better architecture

This 'Changes' bit belongs below the diffstat (so that it doesn't get
included in git commit log). Otherwise looks good so feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> 
> Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  fs/nsfs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 32cb8c835a2b..002d424d9fa6 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -490,8 +490,9 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
>  
>  		VFS_WARN_ON_ONCE(ns->ns_id != fid->ns_id);
>  		VFS_WARN_ON_ONCE(ns->ops->type != fid->ns_type);
> -		VFS_WARN_ON_ONCE(ns->inum != fid->ns_inum);
> -
> +		/* Someone is playing games and passing invalid file handles? */
> +		if (ns->inum != fid->ns_inum)
> +			return NULL;
>  		if (!refcount_inc_not_zero(&ns->count))
>  			return NULL;
>  	}
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[PATCH v2] nsfs: handle inode number mismatches gracefully in file handles

[Deepanshu Kartikey]

Replace VFS_WARN_ON_ONCE() with graceful error handling when file
handles contain inode numbers that don't match the actual namespace
inode. This prevents userspace from triggering kernel warnings by
providing malformed file handles to open_by_handle_at().

The issue occurs when userspace provides a file handle with valid
namespace type and ID that successfully locates a namespace, but
specifies an incorrect inode number. Previously, this would trigger
VFS_WARN_ON_ONCE() when comparing the real inode number against the
provided value.

Since file handle data is user-controllable, inode number mismatches
should be treated as invalid input rather than kernel consistency
errors. Handle this case by returning NULL to indicate the file
handle is invalid, rather than warning about what is essentially
user input validation.

Changes in v2:
- Handle all inode number mismatches, not just zero, as suggested by Jan Kara
- Replace warning with graceful error handling for better architecture

Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/nsfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 32cb8c835a2b..002d424d9fa6 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -490,8 +490,9 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
 
 		VFS_WARN_ON_ONCE(ns->ns_id != fid->ns_id);
 		VFS_WARN_ON_ONCE(ns->ops->type != fid->ns_type);
-		VFS_WARN_ON_ONCE(ns->inum != fid->ns_inum);
-
+		/* Someone is playing games and passing invalid file handles? */
+		if (ns->inum != fid->ns_inum)
+			return NULL;
 		if (!refcount_inc_not_zero(&ns->count))
 			return NULL;
 	}
-- 
2.43.0