[Bug report] ntfs: initialized_size from $LogFile $DATA drives an unvalidated loop bound in ntfs_empty_logfile() - UBSAN shift-out-of-bounds (ilog2) at rw-mount

[Guikun Yang <yangguikun19@qq.com>]

To: ntfs@lists.linux.dev
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
    Namjae Jeon, Hyunchul Lee
Subject: [Bug report] ntfs: initialized_size from $LogFile $DATA drives an
 unvalidated loop bound in ntfs_empty_logfile() - UBSAN
 shift-out-of-bounds (ilog2) at rw-mount

Hi,

While fuzzing single-byte corruptions of NTFS metadata with an automated
mount harness, we found that ntfs_empty_logfile() trusts the on-disk
initialized_size of the LogFile's $DATA attribute as a loop bound without
any check against the runlist or the volume size, and a single flipped
byte in a read-write mount sends the kernel into a shift-out-of-bounds
panic inside the readahead path.

The code (fs/ntfs/logfile.c, ntfs_empty_logfile()):

    end_vcn = (log_ni->initialized_size + vol->cluster_size_mask) >>
          vol->cluster_size_bits;
    ...
    if (rl[1].vcn > end_vcn)
        len = end_vcn - rl->vcn;
    end = NTFS_CLU_TO_B(vol, lcn + len);

    page_cache_sync_readahead(sb->s_bdev->bd_mapping, ra, NULL,
        start >> PAGE_SHIFT, (end - start) >> PAGE_SHIFT);
    ...
    } while ((++rl)->vcn < end_vcn);

The inode loader does validate the on-disk trio against each other
(ntfs_non_resident_sizes_inconsistent(): initialized_size >= 0,
initialized_size <= data_size, data_size <= allocated_size,
allocated_size cluster-aligned). What is missing is any relation between
those sizes and the runlist length or the volume size: initialized_size
is used directly as end_vcn, and the readahead/loop bounds follow it out
of the volume. For comparison, ntfs_check_logfile() scans the LogFile
using i_size (= data_size) truncated to MaxLogFileSize, but that
truncation happens on a local variable only, and ntfs_empty_logfile()
runs afterwards on the untruncated initialized_size.

Trigger: one byte. In a mkntfs-created 64MB image, flip byte 0x4947 in
MFT record 2 (a high byte of the $DATA non-resident size fields) to
0xFF and mount read-write:

    UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
    shift exponent 64 is too large for 64-bit type 'long unsigned int'
    Call Trace:
     ...
     page_cache_sync_ra.cold+0x19/0x46
     ntfs_empty_logfile+0x763/0xd50
     ntfs_fill_super+0x4085/0x71d0
     ...
    Kernel panic - not syncing: UBSAN: panic_on_warn set ...

Reproduced 3/3 runs on a self-built 7.3.0 kernel (CONFIG_NTFS_FS=y,
CONFIG_UBSAN=y) under QEMU/KVM. The function and the missing
runlist/volume bound are unchanged in current mainline.

Notes:

- ntfs_check_logfile() scans with i_size (= data_size, still sane), finds
  no restart pages, reports the LogFile as not empty; the emptying then
  runs anyway on the crafted initialized_size. The panic happens inside
  mount(), before any other syscall.
- A natural fix is to reject or clamp initialized_size (and the derived
  end_vcn) against the runlist extent or the volume size when the inode
  is loaded or when the emptying loop starts. Happy to test a patch.
- This needs a crafted image, like the rest of our NTFS corruption
  testing; we are reporting it because it is a kernel-crashing UBSAN
  violation reachable from mount, the class of bug syzkaller-style
  fuzzing of mount images finds and fixes routinely.

The reproducer bundle (image after the single-byte flip, clean control
image, a moderate-value variant that mounts cleanly, the flip harness,
guest init, and a README with field offsets and expected output) is
available on request.

Environment: QEMU/KVM x86_64, 1 vCPU, self-built 7.3.0 with
CONFIG_NTFS_FS=y, CONFIG_KASAN_GENERIC=y, CONFIG_UBSAN=y. The driver is
fs/ntfs as merged in 7.3.

Thanks,
Guikun Yang