While reviewing an H3 binding, I noticed unchecked signed accumulation in two size calculation functions:
uncompactCellsSize: numOut += childrenSizemaxPolygonToCellsSize: totalVerts += geoPolygon->holes[i].numVerts
For uncompactCellsSize, a concrete boundary case is 1,942,760 copies of a valid non-pentagon resolution-0 cell expanded to resolution 15. Each contributes 7^15 = 4,747,561,509,943 cells, so the mathematical total exceeds INT64_MAX. The example uses duplicates; if those are considered invalid input, they are not rejected before the addition.
For maxPolygonToCellsSize, the vertex counts are accumulated in an int. An overflow can be demonstrated with a three-vertex exterior and one hole reporting INT_MAX vertices. This deliberately uses inconsistent polygon metadata; a structurally consistent case would require more than INT_MAX coordinates and therefore an exceptionally large input.
While triggering these conditions appears to require adversarial inputs unlikely to arise in ordinary use, I wanted to report them because the affected size calculations may directly determine downstream memory allocations and could therefore have security implications.
While reviewing an H3 binding, I noticed unchecked signed accumulation in two size calculation functions:
uncompactCellsSize:numOut += childrenSizemaxPolygonToCellsSize:totalVerts += geoPolygon->holes[i].numVertsFor
uncompactCellsSize, a concrete boundary case is 1,942,760 copies of a valid non-pentagon resolution-0 cell expanded to resolution 15. Each contributes7^15 = 4,747,561,509,943cells, so the mathematical total exceedsINT64_MAX. The example uses duplicates; if those are considered invalid input, they are not rejected before the addition.For
maxPolygonToCellsSize, the vertex counts are accumulated in anint. An overflow can be demonstrated with a three-vertex exterior and one hole reportingINT_MAXvertices. This deliberately uses inconsistent polygon metadata; a structurally consistent case would require more thanINT_MAXcoordinates and therefore an exceptionally large input.While triggering these conditions appears to require adversarial inputs unlikely to arise in ordinary use, I wanted to report them because the affected size calculations may directly determine downstream memory allocations and could therefore have security implications.