Commit 4e8011ffec79 ("ntfs3: pretend $Extend records as regular files")
set the mode for $Extend records to S_IFREG to satisfy VFS requirements.
This made system metadata files appear as regular files, allowing
operations like truncate to be attempted on them.

NTFS system files (inode numbers below MFT_REC_FREE) should not have
their size modified by userspace as this can corrupt the filesystem.
Additionally, the run_lock was not initialized for $Extend records,
causing lockdep warnings when such operations were attempted.

Fix both issues by:
1. Initializing run_lock for $Extend records to prevent crashes
2. Blocking size-change operations on all NTFS system files to prevent
   filesystem corruption

Reported-by: syzbot+3e58a7dc1a8c00243999@syzkaller.appspotmail.com
Tested-by: syzbot+3e58a7dc1a8c00243999@syzkaller.appspotmail.com
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 4e8011ffec79 ("ntfs3: pretend $Extend records as regular files")
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ntfs3/file.c  | 6 +++++-
 fs/ntfs3/inode.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ntfs3/file.c b/fs/ntfs3/file.c
index 4c90ec2fa2ea..c5b2bddb0cee 100644
--- a/fs/ntfs3/file.c
+++ b/fs/ntfs3/file.c
@@ -792,7 +792,11 @@ int ntfs_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
 
 	if (ia_valid & ATTR_SIZE) {
 		loff_t newsize, oldsize;
-
+		/* Prevent size changes on NTFS system files */
+		if (ni->mi.rno < MFT_REC_FREE) {
+			err = -EPERM;
+			goto out;
+		}
 		if (WARN_ON(ni->ni_flags & NI_FLAG_COMPRESSED_MASK)) {
 			/* Should never be here, see ntfs_file_open(). */
 			err = -EOPNOTSUPP;
diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
index 3959f23c487a..180cd984339b 100644
--- a/fs/ntfs3/inode.c
+++ b/fs/ntfs3/inode.c
@@ -472,6 +472,7 @@ static struct inode *ntfs_read_mft(struct inode *inode,
 		/* Records in $Extend are not a files or general directories. */
 		inode->i_op = &ntfs_file_inode_operations;
 		mode = S_IFREG;
+		init_rwsem(&ni->file.run_lock);
 	} else {
 		err = -EINVAL;
 		goto out;
-- 
2.43.0

Hi Tetsuo,

Thank you for testing on a legitimate filesystem and for your question.

I'm trying to understand the protection mechanism better. When I searched
for ENXIO in fs/ntfs3/, I didn't find any explicit checks. Could you help
me understand where the ENXIO is coming from in your test?

I noticed that in the $Extend code path, inode->i_fop doesn't appear to
be set (only i_op is set), unlike regular files. Could this be why
operations fail on legitimate filesystems?

Regarding the syzbot reproducer - it uses a malformed filesystem image
from the fuzzer. I'm wondering if such corrupted images might bypass the
normal protections and reach ntfs_setattr() in ways that don't happen on
proper filesystems.

Would it make sense to add an explicit check in ntfs_setattr() to reject
size changes on system inodes (rno < MFT_REC_FREE) as additional
protection? Or do you think Edward's patch (just initializing the lock)
is sufficient?

I'd appreciate your guidance on the right approach here.

Best regards,
Deepanshu

On 2025/10/14 23:39, Deepanshu Kartikey wrote:
> NTFS system files (inode numbers below MFT_REC_FREE) should not have
> their size modified by userspace as this can corrupt the filesystem.

Excuse me, but how can truncate operation succeed? As far as I tested,
truncate operation on files in $Extend directory fails even without your patch
( https://lkml.kernel.org/r/842b3b43-0a1c-4fe8-adff-94fdb2cee59b@I-love.SAKURA.ne.jp ).
Are there other NTFS system files which do not belong to $Extend directory?