Hi Ntfs3 developers,
I've run into a seemingly ntfs driver issue and I would like to have
your advice on how to proceed.
The issue happens on a 32bit multi-core ARM system running Linux
6.1.83 LTS (+CPU and SOM vendor patches) while doing USB stick mount
stress testing. The tests repeatedly unmount and mount the same stick
and result in a kernel Oops (null pointer dereference) in a few hours
with similar stacks:
Stack1
kernel: mi_enum_attr from ntfs_iget5+0x520/0x182c
kernel: ntfs_iget5 from ntfs_fill_super+0x15b0/0x190c
kernel: ntfs_fill_super from get_tree_bdev+0x270/0x3c0
kernel: get_tree_bdev from vfs_get_tree+0x60/0x20c
kernel: vfs_get_tree from path_mount+0xa90/0x113c
kernel: path_mount from do_mount+0xa8/0xbc
kernel: do_mount from sys_mount+0x3d4/0x4e8
kernel: sys_mount from ret_fast_syscall+0x0/0x1c
Stack2
kernel: mi_read from ntfs_iget5+0x230/0x182c
kernel: ntfs_iget5 from ntfs_fill_super+0x15b0/0x190c
(frames below ntfs_iget5 are identical to above)
Searching for ntfs_iget5 in Google showed some syzkaller reports:
https://syzkaller.appspot.com/bug?extid=b4084c18420f9fad0b4f
Looks similar, fixed on upstream, but upstream diverged from LTS
so much that I couldn't even after considering other changes.
https://syzkaller.appspot.com/bug?id=5332433f628f47da0efad0982d47e5a0602668b8
Looks similar, reported on LTS kernel, but abandonned.
https://lore.kernel.org/ntfs3/20240820105342.79788-1-llfamsec@xxxxxxxxx/T/#t
The usecase is not mount, but frame mi_enum_attr is identical.
Question: is this a known issue with an existing fix or something new?
If a fix exists somewhere it would be great to have some pointers. I'm
not a kernel developer, but I can do semi-intelligent-manual-patching.
:) If it's something new, I'm happy to share more details.
Any help appreciated!
Regards,
Gyorgy
