Summary
In mlir/lib/Target/DXSA/BinaryParser.cpp, token reads during instruction decoding are bounded only by the end of the program buffer, not by the current instruction's declared length. Operands have variable length (index DWORDs, l(...)/d(...) immediate payloads, the extended operand token, nested operands for relative indexing), so a malformed operand can read past the instruction boundary (beginOffset + length * tokenSize) into the tokens of the following instruction before the mismatch is noticed.
Current behavior
parseToken only checks the buffer end:
Proposed fix
Deserializer slices each instruction to its declared token count up front and decodes operands strictly within that slice (window), so an operand physically cannot cross the boundary and fails right at it.
Summary
In
mlir/lib/Target/DXSA/BinaryParser.cpp, token reads during instruction decoding are bounded only by the end of the program buffer, not by the current instruction's declared length. Operands have variable length (index DWORDs,l(...)/d(...)immediate payloads, the extended operand token, nested operands for relative indexing), so a malformed operand can read past the instruction boundary (beginOffset + length * tokenSize) into the tokens of the following instruction before the mismatch is noticed.Current behavior
parseTokenonly checks the buffer end:Proposed fix
Deserializer slices each instruction to its declared token count up front and decodes operands strictly within that slice (window), so an operand physically cannot cross the boundary and fails right at it.