lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6xveadhfw4mznkxo653oa5xnfl2jdwvhiah4if6mcjeqlmzelo@tov4lqlczoas>
Date: Wed, 24 Sep 2025 13:12:58 +0200
From: Jan Kara <jack@...e.cz>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzbot+9eefe09bedd093f156c2@...kaller.appspotmail.com
Subject: Re: [PATCH] nsfs: reject file handles with invalid inode number

On Wed 24-09-25 06:58:15, Deepanshu Kartikey wrote:
> Reject nsfs file handles that claim to have inode number 0, as no
> legitimate namespace can have inode 0. This prevents a warning in
> nsfs_fh_to_dentry() when open_by_handle_at() is called with malformed
> file handles.
> 
> The issue occurs when userspace provides a file handle with valid
> namespace type and ID but claims the namespace has inode number 0.
> The namespace lookup succeeds but triggers VFS_WARN_ON_ONCE() when
> comparing the real inode number against the impossible claim of 0.
> 
> Since inode 0 is reserved in all filesystems and no namespace can
> legitimately have inode 0, we can safely reject such handles early
> to prevent reaching the consistency check that triggers the warning.
> 
> Testing confirmed that other invalid inode numbers (1, 255) do not
> trigger the same issue, indicating this is specific to inode 0 rather
> than a general problem with incorrect inode numbers.

Thanks for report and the analysis but looking at the code I'm confused.
How come that if the filehandle has correct 'id' but incorrect 'inum', it
doesn't trigger the warning? I think the check:

VFS_WARN_ON_ONCE(ns->inum != fid->ns_inum);

should just be turned into:

	/* Someone is playing games and passing invalid file handles? */
	if (ns->inum != fid->ns_inum)
		return NULL;

								Honza
> 
> 
> Reported-by: syzbot+9eefe09bedd093f156c2@...kaller.appspotmail.com
> Tested-by: syzbot+9eefe09bedd093f156c2@...kaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>
> 
> ---
>  fs/nsfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 32cb8c835a2b..42672cec293c 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -469,7 +469,8 @@ static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
>  
>  	if (fh_len < NSFS_FID_SIZE_U32_VER0)
>  		return NULL;
> -
> +	if (fid->ns_inum == 0)
> +		return NULL;
>  	/* Check that any trailing bytes are zero. */
>  	if ((fh_len > NSFS_FID_SIZE_U32_LATEST) &&
>  	    memchr_inv((void *)fid + NSFS_FID_SIZE_U32_LATEST, 0,
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ