Re: [PATCH] fs/ntfs3: reject evcn == U64_MAX in mi_enum_attr()

[Zhan Xusheng]

On Fri, 24 Apr 2026 16:15:58 +0100
David Laight <david.laight.linux@xxxxxxxxx> wrote:

> Is that analysis correct? with the current code:
> If evcn is 2 then everything except 0, 1, 2 and 3 are errors.
> If evcn is -3 then only -1 is an error.
> If evcn is -2 no values are errors.
> If evcn is -1 then all svcn values except 0 are errors.
>
> Clearly this doesn't make sense if evcn is -1.
>
> But there isn't an obvious reason why svcn == -4, evcn == -1
> shouldn't be a valid range.
> (There might be a sanity upper limit is evcn for other reasons.)

Thanks for looking into this, David.

The on-disk svcn/evcn fields are __le64 (ntfs.h:339-340), and ntfs3
uses them as u64 throughout -- the internal VCN type CLST is typedef'd
to u32 or u64 (ntfs.h:73-78).  NTFS VCNs are unsigned by definition;
there is no such thing as a negative VCN.

So the signed interpretation doesn't apply here.  In the unsigned
domain, 0xFFFFFFFFFFFFFFFF is simply the maximum u64 value, not -1.
The only issue is the arithmetic wrap: (u64)0xFFFFFFFFFFFFFFFF + 1 == 0.

Regarding a separate upper bound: yes, evcn is also bounded by the
volume's total cluster count, but mi_enum_attr() validates on-disk
MFT records before the superblock fields are necessarily available
to every caller, so the U64_MAX check is the minimal fix for the
overflow.

Thanks,
Zhan Xusheng