mirror of
https://github.com/open62541/open62541.git
synced 2026-10-17 04:42:09 +08:00
StalderT
07be1409d5
UA_readNumberWithBase multiplied without an overflow check, so "4294967296" was read as 0 and "4294967297" as 1. In an IndexRange that silently returned element 1 with a Good status, and the same wrap applied to a NodeId like "i=4294967297" or a port in an endpoint URL. UA_readNumberWithBase now returns zero digits when the number does not fit into 32 bits, which every caller already treats as invalid. An IndexRange index above 32 bits still has a valid syntax, so the NumericRange parser saturates it instead of rejecting it. The range checks then return Bad_IndexRangeNoData beyond the lower bound and partial results beyond the upper bound, as Part 4, 7.27 asks. UA_NumericRange_parse also accepted any number of dimensions and grew its array by two entries per realloc, so one long IndexRange string meant millions of reallocations for a range that copyRange and setRange reject anyway above UA_MAX_ARRAY_DIMS. The parser now stops at that limit with Bad_IndexRangeNoData.