a negative ntfs superblock mft_lcn can cause a wild memory reference

a negative ntfs superblock mft_lcn can cause a wild memory reference

[rtm]

If the ntfs superblock's mft_lcn is negative, that will pass tests
such as

        ll = le64_to_cpu(b->mft_lcn);
        if (ll >= vol->nr_clusters) {

and 

        vol->mft_zone_end = vol->mft_lcn + mft_zone_size;
        while (vol->mft_zone_end >= vol->nr_clusters) {

because the variables are signed.

The attached corrupt NTFS image exploits this to cause index to be
out of bounds in ntfs_cluster_alloc(), e.g. for

                if (vol->lcn_empty_bits_per_page[index] == 0)
                        goto next_bmp_pos;

index is derived from mft_lcn via mft_zone_end, data1_zone_pos,
zone_start, and bmp_pos.

# wget http://www.rtmrtm.org/rtm/ntfs8b.img.gz
# gunzip ntfs8b.img.gz
# cp ntfs8b.img junk
# mount -t ntfs -o loop junk /mnt
# echo x > /mnt/x
ntfs: (device loop0): check_mft_mirror(): $MFT and $MFTMirr record 0 do not match.  Run chkdsk.
BUG: unable to handle page fault for address: ffff80010e38ef58
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
CPU: 10 UID: 0 PID: 1264 Comm: tcsh Not tainted 7.2.0-rc7-00016-g3d6d817622b0 #40 PREEMPT(full)
Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
RIP: 0010:ntfs_cluster_alloc+0x376/0x12a0
Call Trace:
 <TASK>
 ? inode_io_list_move_locked+0xa1/0xe0
 ? folio_mark_dirty+0x33/0x60
 ntfs_mft_data_extend_allocation_nolock+0x15b/0xa30
 ntfs_mft_record_alloc+0x921/0x1790
 __ntfs_create+0x1c4/0xd40
 ? ntfs_attr_put_search_ctx+0x3b/0x50
 ? kmem_cache_free+0x207/0x2f0
 ? __mark_inode_dirty+0x16a/0x3b0
 ntfs_create+0xc1/0x170
 path_openat+0xfe0/0x12f0
 ? do_syscall_64+0xf9/0x540
 ? do_getname+0x2e/0x180
 do_file_open+0xdf/0x1a0
 do_sys_openat2+0x79/0xe0
 __x64_sys_creat+0x49/0x70
 x64_sys_call+0x1bfa/0x2130
 do_syscall_64+0xf9/0x540
 ? exc_page_fault+0x76/0x130
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Robert Morris
rtm@mit.edu

Re: a negative ntfs superblock mft_lcn can cause a wild memory reference

[Hyunchul Lee]

Hi Robert,

I have submitted a patch to fix this issue:

https://lore.kernel.org/all/20260818-fix-negative-mft-lcn-v1-1-b7b0b206f2da@gmail.com/

2026년 8월 18일 (화) 오전 6:03, <rtm@csail.mit.edu>님이 작성:
>
> If the ntfs superblock's mft_lcn is negative, that will pass tests
> such as
>
>         ll = le64_to_cpu(b->mft_lcn);
>         if (ll >= vol->nr_clusters) {
>
> and
>
>         vol->mft_zone_end = vol->mft_lcn + mft_zone_size;
>         while (vol->mft_zone_end >= vol->nr_clusters) {
>
> because the variables are signed.
>
> The attached corrupt NTFS image exploits this to cause index to be
> out of bounds in ntfs_cluster_alloc(), e.g. for
>
>                 if (vol->lcn_empty_bits_per_page[index] == 0)
>                         goto next_bmp_pos;
>
> index is derived from mft_lcn via mft_zone_end, data1_zone_pos,
> zone_start, and bmp_pos.
>
> # wget http://www.rtmrtm.org/rtm/ntfs8b.img.gz
> # gunzip ntfs8b.img.gz
> # cp ntfs8b.img junk
> # mount -t ntfs -o loop junk /mnt
> # echo x > /mnt/x
> ntfs: (device loop0): check_mft_mirror(): $MFT and $MFTMirr record 0 do not match.  Run chkdsk.
> BUG: unable to handle page fault for address: ffff80010e38ef58
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
> CPU: 10 UID: 0 PID: 1264 Comm: tcsh Not tainted 7.2.0-rc7-00016-g3d6d817622b0 #40 PREEMPT(full)
> Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
> RIP: 0010:ntfs_cluster_alloc+0x376/0x12a0
> Call Trace:
>  <TASK>
>  ? inode_io_list_move_locked+0xa1/0xe0
>  ? folio_mark_dirty+0x33/0x60
>  ntfs_mft_data_extend_allocation_nolock+0x15b/0xa30
>  ntfs_mft_record_alloc+0x921/0x1790
>  __ntfs_create+0x1c4/0xd40
>  ? ntfs_attr_put_search_ctx+0x3b/0x50
>  ? kmem_cache_free+0x207/0x2f0
>  ? __mark_inode_dirty+0x16a/0x3b0
>  ntfs_create+0xc1/0x170
>  path_openat+0xfe0/0x12f0
>  ? do_syscall_64+0xf9/0x540
>  ? do_getname+0x2e/0x180
>  do_file_open+0xdf/0x1a0
>  do_sys_openat2+0x79/0xe0
>  __x64_sys_creat+0x49/0x70
>  x64_sys_call+0x1bfa/0x2130
>  do_syscall_64+0xf9/0x540
>  ? exc_page_fault+0x76/0x130
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Robert Morris
> rtm@mit.edu
>


-- 
Thanks,
Hyunchul