[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

[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]

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

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]

在 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.