Summary

The ISO9660 version-number parser accumulates digits into a signed int on both sides: user-supplied at :118 (i = i*10 + *fn++ - '0') and image-supplied at :123 (j = j*10 + c - '0'), then returns i - j at :127. Version fields >=10 digits (e.g. 'NAME;4294967297') overflow int (UB, wraps mod 2^32) so lookup('NAME;4294967297') compares i==1 and matches an image entry 'NAME;1'. isofncmp returns 0 (exact match) for unequal names; cd9660_lookup.c:233 treats 0 as exact. Image-side loop also performs no digit validation (c is an arbitrary u_short). Honest ceiling: LOW/none as a boundary crossing - iso9660 is read-only/ACL-less, a false-positive match only resolves an entry the requester could address by its true name; no memory corruption (stack locals). UB noise, ISO9660 semantics divergence, theoretical confusion vs programs treating 'X;N' as distinct. Fix: clamp accumulators + validate image-side digits. [VERIFIED pass2: reproduced - crafted plain-ISO stat NAME 4294967297 matches NAME 1 on stock via 2 to the 32 plus 1 wrapping the int accumulator; F40FIX ENOENT with NAME 1 unchanged]