Opened 6 years ago

Closed 5 years ago

#2697 closed defect (fixed)

ST_GeomFromGeoJSON() of invalid GeoJSON Polygons crashes server process, possibly corrupts shared memory

Reported by: kochb Owned by: pramsey
Priority: high Milestone: PostGIS 2.1.3
Component: postgis Version: 2.1.x
Keywords: history Cc: tusharahuja

Description

When trying to ST_GeomFromGeoJSON certain invalid geojson strings, the server process crashes and forces other clients to disconnect.

Though this is certainly errant geojson, I would expect any error generated by a query to not affect unrelated server connections.

To Reproduce

Open two psql connections. In the first, run the following query:

test=> SELECT ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[1,1]}');

You should receive the following error:

SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Failed.
!> 

In the second, run any query:

test=> \dt
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Failed.
!> 

Version Info

Postgres version: PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro? 4.6.3-1ubuntu5) 4.6.3, 64-bit

PostGIS full version: POSTGIS="2.1.1 r12113" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

Change History (10)

comment:1 Changed 6 years ago by pramsey

Milestone: PostGIS 2.1.3

Confirmed, takes down OSX as well, and on the latest tip from the branch. If you know of other JSON variants that take down the server, this would be a good time to post them, so I can fix them all in one go.

comment:2 Changed 6 years ago by kochb

One other instance:

ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[1]}')

But other odd ones are just fine:

ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[[1],[1]]}')
ST_GeomFromGeoJSON('{"type":"MultiPolygon","coordinates":[1]}')
ST_GeomFromGeoJSON('{"type":"MultiPolygon","coordinates":[1,1]}')

Haven't been able to trigger this with numerous other geometry types. Might be simply restricted to one dimensional arrays on polygon GeoJSON.

comment:3 Changed 6 years ago by pramsey

Resolution: fixed
Status: newclosed

Fixed in 2.1 branch at r12410, trunk at r12411

comment:4 Changed 6 years ago by robe

Keywords: history added

comment:5 Changed 6 years ago by strk

Ouch. We've used zzuf with great benefit during Gnash development. The tool produces pseudo-random distortions on a given input, in a way that you can predictably reproduce. Excellent to test robustness of parsers. See http://caca.zoy.org/wiki/zzuf

comment:6 Changed 6 years ago by strk

No love for 2.0 ?

comment:7 Changed 6 years ago by strk

Resolution: fixed
Status: closedreopened

ST_GeomFromGML was introduced in 1.5, btw

comment:8 Changed 6 years ago by strk

Resolution: fixed
Status: reopenedclosed

I tested and neither 2.0.5 nor 1.5.9SVN are affected

comment:9 Changed 5 years ago by tusharahuja

Cc: tusharahuja added
Resolution: fixed
Status: closedreopened

Hi,

This issue is reproducible on postGIS 2.0.6 against PG 9.2.9 (Linux32/64)

--PG Version

postgres=# select version();

version


PostgreSQL 9.2.9 on i686-pc-linux-gnu, compiled by gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4), 32-bit

(1 row)

--postGIS version -

postgres=# select postgis_full_version();

postgis_full_version


POSTGIS="2.0.6 r12554" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.7" LIBJSON="UNKNOWN"

(1 row)

--crash Query -

postgres=# SELECT '#2697', ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[1]}'); The connection to the server was lost. Attempting reset: WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. Failed.

comment:10 Changed 5 years ago by pramsey

Resolution: fixed
Status: reopenedclosed

Fixed in 2.0 at r12957, thanks!

Note: See TracTickets for help on using tickets.