Re: [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

[liubaolin <liubaolin12138@163.com>]

在 2026/10/31 20:00, Guikun Yang 写道:
> 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

Hi Guikun,

    Thanks for the report.
    I had a look at the latest ntfs-next and think this may already be 
addressed by two commits.

    8e9137915220 (“ntfs: reject non-resident attributes whose sizes 
exceed their allocation”) adds the size checks you mentioned. With the 
layout you described, setting byte 0x4947 to 0xff would make 
initialized_size negative, so loading the LogFile inode should fail 
before we get to ntfs_empty_logfile().
    Also, 749357bd48c16 (“ntfs: mount hibernated volumes read-only 
regardless of errors=”) makes the mount read-only if errors were 
recorded earlier. This includes a failed LogFile check, so the case 
where no restart pages are found should no longer proceed to emptying 
the logfile, even with errors=continue.

    Could you retest with the latest ntfs-next and see whether it still 
happens? The current tip is 564c77536477.

Thanks,
Baolin.