* Forwarded: [PATCH] nsfs: validate file handle type in nsfs_fh_to_dentry()
2025-09-20 0:13 [syzbot] [nfs?] WARNING in nsfs_fh_to_dentry syzbot
@ 2025-09-20 8:11 ` syzbot
2025-09-21 0:54 ` Forwarded: [PATCH] nsfs: validate file handle type and data " syzbot
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: syzbot @ 2025-09-20 8:11 UTC (permalink / raw)
To: linux-kernel
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.
***
Subject: [PATCH] nsfs: validate file handle type in nsfs_fh_to_dentry()
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
Add early validation of file handle type in nsfs_fh_to_dentry() to
prevent processing of handles with incorrect types. This fixes a
warning triggered when open_by_handle_at() is called with non-nsfs
handle types on nsfs files.
The issue occurs when a user provides a file handle with a type
like FILEID_INO32_GEN_PARENT (0xf1) instead of FILEID_NSFS when
calling open_by_handle_at() on an nsfs file. The generic export
code routes this to nsfs_fh_to_dentry(), which then processes
the incorrectly formatted handle data, leading to validation
warnings.
Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/nsfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/nsfs.c b/fs/nsfs.c
index 32cb8c835a2b..050e7db80297 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -461,6 +461,8 @@ static int nsfs_encode_fh(struct inode *inode, u32 *fh, int *max_len,
static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
int fh_len, int fh_type)
{
+ if (fh_type != FILEID_NSFS)
+ return ERR_PTR(-EINVAL);
struct path path __free(path_put) = {};
struct nsfs_file_handle *fid = (struct nsfs_file_handle *)fh;
struct user_namespace *owning_ns = NULL;
--
2.43.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Forwarded: [PATCH] nsfs: validate file handle type and data in nsfs_fh_to_dentry()
2025-09-20 0:13 [syzbot] [nfs?] WARNING in nsfs_fh_to_dentry syzbot
2025-09-20 8:11 ` Forwarded: [PATCH] nsfs: validate file handle type in nsfs_fh_to_dentry() syzbot
@ 2025-09-21 0:54 ` syzbot
2025-09-21 3:19 ` Forwarded: [PATCH] nsfs: reject file handles with invalid inode number syzbot
2025-09-21 5:23 ` syzbot
3 siblings, 0 replies; 5+ messages in thread
From: syzbot @ 2025-09-21 0:54 UTC (permalink / raw)
To: linux-kernel
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.
***
Subject: [PATCH] nsfs: validate file handle type and data in nsfs_fh_to_dentry()
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
Add comprehensive validation of file handle type and data in
nsfs_fh_to_dentry() to prevent processing of handles with incorrect
types or malformed data. This fixes a warning triggered when
open_by_handle_at() is called with invalid handle data on nsfs files.
The issue occurs when a user provides a file handle with an incorrect
handle type or valid FILEID_NSFS type but malformed data structure.
Although the export subsystem routes the call to nsfs, the function
needs to validate that both the handle type and data are appropriate
for nsfs files.
The reproducer sends fh_type=0xf1 (FILEID_NSFS) but with a data
structure from FILEID_INO32_GEN_PARENT, resulting in invalid ns_type
values that trigger warnings in the namespace lookup code.
Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/nsfs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/nsfs.c b/fs/nsfs.c
index 32cb8c835a2b..7f3c8e8c97e2 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -461,8 +461,17 @@ static int nsfs_encode_fh(struct inode *inode, u32 *fh, int *max_len,
static struct dentry *nsfs_fh_to_dentry(struct super_block *sb, struct fid *fh,
int fh_len, int fh_type)
{
+ if (fh_type != FILEID_NSFS)
+ return ERR_PTR(-EINVAL);
+ if (fh_len < sizeof(struct nsfs_file_handle) / sizeof(u32))
+ return ERR_PTR(-EINVAL);
struct path path __free(path_put) = {};
struct nsfs_file_handle *fid = (struct nsfs_file_handle *)fh;
+ if (fid->ns_type != CLONE_NEWNS && fid->ns_type != CLONE_NEWCGROUP &&
+ fid->ns_type != CLONE_NEWUTS && fid->ns_type != CLONE_NEWIPC &&
+ fid->ns_type != CLONE_NEWUSER && fid->ns_type != CLONE_NEWPID &&
+ fid->ns_type != CLONE_NEWNET)
+ return ERR_PTR(-EINVAL);
struct user_namespace *owning_ns = NULL;
struct ns_common *ns;
int ret;
--
2.43.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Forwarded: [PATCH] nsfs: reject file handles with invalid inode number
2025-09-20 0:13 [syzbot] [nfs?] WARNING in nsfs_fh_to_dentry syzbot
2025-09-20 8:11 ` Forwarded: [PATCH] nsfs: validate file handle type in nsfs_fh_to_dentry() syzbot
2025-09-21 0:54 ` Forwarded: [PATCH] nsfs: validate file handle type and data " syzbot
@ 2025-09-21 3:19 ` syzbot
2025-09-21 5:23 ` syzbot
3 siblings, 0 replies; 5+ messages in thread
From: syzbot @ 2025-09-21 3:19 UTC (permalink / raw)
To: linux-kernel
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.
***
Subject: [PATCH] nsfs: reject file handles with invalid inode number
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
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.
Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Forwarded: [PATCH] nsfs: reject file handles with invalid inode number
2025-09-20 0:13 [syzbot] [nfs?] WARNING in nsfs_fh_to_dentry syzbot
` (2 preceding siblings ...)
2025-09-21 3:19 ` Forwarded: [PATCH] nsfs: reject file handles with invalid inode number syzbot
@ 2025-09-21 5:23 ` syzbot
3 siblings, 0 replies; 5+ messages in thread
From: syzbot @ 2025-09-21 5:23 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] nsfs: reject file handles with invalid inode number
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
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.
Reported-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Tested-by: syzbot+9eefe09bedd093f156c2@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.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
^ permalink raw reply related [flat|nested] 5+ messages in thread