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

[David Laight]

On Sat, 25 Apr 2026 10:03:09 +0800
Zhan Xusheng <zhanxusheng1024@xxxxxxxxx> wrote:

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

I was just writing negative values as shorthand for unsigned ones
just below the ~0ull.
Perhaps I should have added the (u64) cast.

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

True - but your comment is wrong.
And if the code was looping through the range, I suspect there are
other values that would also lead to is looping ~forever.

If the numbers are relative the to physical media then the maximum
size is much smaller.
Basically you can't have 2^64 of anything - there aren't enough atoms.
So you can use a much smaller 'sanity check' - limit possibly earlier on.

	David

> 
> Thanks,
> Zhan Xusheng