linux-kernel - Re: [PATCH] ntfs3: prevent operations on NTFS system files

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADhLXY6zA0EGhKjzBZXSv3QFC2OMHxTxzgZy2sObzNaaza7eLg@mail.gmail.com>
Date: Tue, 14 Oct 2025 20:51:52 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: almaz.alexandrovich@...agon-software.com, 
	penguin-kernel@...ove.sakura.ne.jp
Cc: ntfs3@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	syzbot+3e58a7dc1a8c00243999@...kaller.appspotmail.com
Subject: Re: [PATCH] ntfs3: prevent operations on NTFS system files

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