Undefined behavior in decode_geohash_bbox with invalid input

[mentin]

decode_geohash_bbox uses this code to convert geohash version of base32 to integer:

721          for (i = 0; i < precision; i++)
722          {
723              c = tolower(geohash[i]);
724              cd = strchr(base32, c) - base32;
725	

If the input is not a valid geohash, the strchr returns NULL, the result is a constant that depends of how linker loaded 'base32' field. There is no security vulnerability here, since NULL is never dereferenced, and only 5 bits of 'cd' are used, but the result is undefined (even though it is constant for any specific build).

E.g. in my PostgreSQL build, I'm getting ST_PointFromGeoHash("@@@@@@") equal to ST_PointFromGeoHash("gggggg"), meaning my 'base32' was at some offset representable as 32*n + 16.

Should this query fail in PostGIS?

Should this return something well defined?

[Algunenano]

PR in ​https://github.com/postgis/postgis/pull/420

Changes the decoding procedure to throw on invalid characters:

# Select ST_PointFromGeoHash('@@@@@@');
ERROR:  decode_geohash_bbox: Invalid character '@'

[Raul Marin]

In 17526:

Throw on invalid characters when decoding geohash

References #4406

[Raul Marin]

In 17527:

Throw on invalid characters when decoding geohash

References #4406

[Raul Marin]

In 17528:

Throw on invalid characters when decoding geohash

References #4406

[Raul Marin]

In 17529:

Throw on invalid characters when decoding geohash

Closes #4406
Closes ​https://github.com/postgis/postgis/pull/420