Since major API changes PROJ >= 5, the introduction of PJ_COORD, a union type, has caused uninitialized memory reads in certain situations.
This issue manifests when using functions like proj_trans, leading to undefined behavior and potential crashes.
We observed this behavior on RHEL9 (using proj-8.2.0-1.rhel9.x86_64), where the reads resulted in PROJ returning -nan values when debugging the output in composite.c.
Interestingly, we did not observe the same issue on Ubuntu, but Valgrind detected these issues on both platforms.
The following Valgrind output illustrates the problem:
==26291== Conditional jump or move depends on uninitialised value(s)
==26291== at 0x6234F5F: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x62359FF: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x6241B07: proj_trans (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x6245310: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x6235917: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x6241B07: proj_trans (in /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1)
==26291== by 0x5F4531F: ProjectionPipeline_inv (projection_pipeline.c:354)
==26291== by 0x5F60112: CartesianOdimIOInternal_addLonLatExtentToAttributeList (cartesian_odim_io.c:1002)
==26291== by 0x5F61DA6: CartesianOdimIO_fillImage (cartesian_odim_io.c:1230)
==26291== by 0x5F47906: RaveIOInternal_addCartesianToNodeList (rave_io.c:406)
==26291== by 0x5F47906: RaveIO_save (rave_io.c:694)
==26291== by 0x48665BB: _pyraveio_save (pyraveio.c:260)
==26291== by 0x262137: ??? (in /usr/bin/python3.10)
==26291== Uninitialised value was created by a stack allocation
==26291== at 0x5F45280: ProjectionPipeline_inv (projection_pipeline.c:335)
Solution:
The solution is to initialize the PJ_COORD union to zero wherever it is used in the codebase.
IE-smhi
commented
5 months ago
Description
Since major API changes PROJ >= 5, the introduction of PJ_COORD, a union type, has caused uninitialized memory reads in certain situations.
This issue manifests when using functions like proj_trans, leading to undefined behavior and potential crashes.
We observed this behavior on RHEL9 (using proj-8.2.0-1.rhel9.x86_64), where the reads resulted in PROJ returning -nan values when debugging the output in composite.c. Interestingly, we did not observe the same issue on Ubuntu, but Valgrind detected these issues on both platforms.
The following Valgrind output illustrates the problem:
Solution:
The solution is to initialize the PJ_COORD union to zero wherever it is used in the codebase.