[Security] Stack buffer overflow in GTIFProj4ToLatLong via listgeo (ASAN stack-buffer-overflow, WRITE of size 253)

Start with GTIFProj4AppendEllipsoid() in src/libgeotiff/geotiff_proj4.c near line 47, where the unbounded sprintf() writes the ellipsoid parameters, and trace its callers in GTIFProj4ToLatLong() (around line 1433) and GTIFProj4FromLatLong() (around line 1376), plus GTIFGetProj4Defn() (around line 1342). Build with AddressSanitizer, run listgeo on the attached crash-input.bin, and confirm the stack-buffer-overflow is gone while negative-control.bin still prints its corner coordinates. Done means bounded formatting at every call site with no ASAN report.

[Security] Stack buffer overflow in GTIFProj4ToLatLong via listgeo (ASAN stack-buffer-overflow, WRITE of size 253)

2. Summary

A crafted GeoTIFF file triggers a stack buffer overflow in GTIFProj4ToLatLong() (geotiff_proj4.c) when the listgeo utility prints the corner coordinates of the file. AddressSanitizer reports a stack-buffer-overflow WRITE of size 253 landing at the end of the fixed 256-byte stack buffer szLongLat[256]; the write comes from an unbounded sprintf() inside GTIFProj4AppendEllipsoid() (geotiff_proj4.c:47), which appends the "+a=%.3f +b=%.3f " ellipsoid parameters derived from attacker-controlled GeoTIFF keys without any bound check. A prior stack overflow in the same tool (CVE-2014-8330, fixed in 1.4.1) was at a different code site; this is a distinct bug, not an incomplete fix of that one.

3. Affected version / environment

- Repository: https://github.com/OSGeo/libgeotiff
- Tested commit: master @ 75cfca539667c6483e796b24b78ecef72e311a1a (commit date 2026-08-11; tree cloned 2026-10-26)
- Component: libgeotiff/geotiff_proj4.c (GTIFProj4ToLatLong / inlined GTIFProj4AppendEllipsoid), reached from the listgeo utility (bin/listgeo.c:197 GTIFReportACorner)
- Build: AddressSanitizer-instrumented build of the listgeo CLI (/lh/libgeotiff/install/bin/listgeo in the verification container)
- Platform: x86_64 Linux (Docker container); no release tarball was tested, so the set of affected released versions is [unknown]

4. Steps to reproduce

1. Build libgeotiff (master, commit 75cfca539667c6483e796b24b78ecef72e311a1a or current master) with AddressSanitizer, e.g. configure CMake with -DCMAKE_C_FLAGS="-fsanitize=address -g -O1" and build the listgeo utility.
2. Save the attached crash-input.bin (SHA256 efc9eb3f37b28b4cee9ecccba929772e70d6a4f1fdaed4da43fd12655923ce9b) to disk.
3. Run: listgeo /path/to/crash-input.bin
4. Observe the AddressSanitizer report below (exit status 1).
5. Sanity check: run listgeo on the attached negative-control.bin (SHA256 3e66bd033643588974f6d4088ed3bb4642ff701d01241809744aa41179934f5c), a well-formed EPSG:27563 GeoTIFF; it prints the full metadata and corner coordinates with no sanitizer report, confirming the crash comes from the crafted content and not from the environment.

5. Expected behavior

listgeo prints the GeoTIFF metadata and corner coordinates, or cleanly rejects malformed input; no memory-safety error occurs for any input file.

6. Actual behavior

AddressSanitizer aborts listgeo with a stack-buffer-overflow while printing the Upper Left corner coordinate. Full report from a fresh run (2026-11-02):

TIFFFetchNormalTag: Warning, ASCII value for tag "GeoASCIIParams" does not end in null byte.
=================================================================
==560060==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe27cbae80 at pc 0x563217502a70 bp 0x7ffe27cbac60 sp 0x7ffe27cba400
WRITE of size 253 at 0x7ffe27cbae80 thread T0
    #0 0x563217502a6f in __interceptor_vsprintf (/lh/libgeotiff/install/bin/listgeo+0x90a6f) (BuildId: 52049c409ed40bac7dd7eb994997900c86bd3659)
    #1 0x563217503a53 in sprintf (/lh/libgeotiff/install/bin/listgeo+0x91a53) (BuildId: 52049c409ed40bac7dd7eb994997900c86bd3659)
    #2 0x5632175c40da in GTIFProj4ToLatLong /lh/libgeotiff/src/libgeotiff/geotiff_proj4.c:1433:5
    #3 0x56321759fa52 in GTIFReportACorner /lh/libgeotiff/src/libgeotiff/bin/listgeo.c:197:13
    #4 0x56321759efcb in GTIFPrintCorners /lh/libgeotiff/src/libgeotiff/bin/listgeo.c:244:10
    #5 0x56321759efcb in main /lh/libgeotiff/src/libgeotiff/bin/listgeo.c:141:17
    #6 0x7f08c2928d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #7 0x7f08c2928e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #8 0x5632174e0684 in _start (/lh/libgeotiff/install/bin/listgeo+0x6e684) (BuildId: 52049c409ed40bac7dd7eb994997900c86bd3659)
Address 0x7ffe27cbae80 is located in stack of thread T0 at offset 288 in frame
    #0 0x5632175c3f6f in GTIFProj4ToLatLong /lh/libgeotiff/src/libgeotiff/geotiff_proj4.c:1420
This frame has 3 object(s):
    [32, 288) 'szLongLat' (line 1431)
    [352, 384) 'coord' (line 1449) <== Memory access at offset 288 partially underflows this variable
    [416, 448) 'tmp' (line 1455) <== Memory access at offset 288 partially underflows this variable
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lh/libgeotiff/install/bin/listgeo+0x90a6f) (BuildId: 52049c409ed40bac7dd7eb994997900c86bd3659) in __interceptor_vsprintf
==560060==ABORTING

(Stack and shadow addresses are ASLR-dependent and differ between runs; the report was reproduced consistently on every run, and terminal screenshots are available on request.)

7. Impact

listgeo is a command-line inspection utility, so exploitation requires a scenario where the tool runs on attacker-supplied input (for example automated GeoTIFF triage pipelines that run listgeo on uploaded or downloaded rasters and parse its output). The overflow smashes a 256-byte stack buffer in GTIFProj4ToLatLong() with several hundred bytes of attacker-influenced formatted text (the ellipsoid semi-major/semi-minor axis values are rendered with "%.3f"), which reliably crashes the process and, in principle, can overwrite stack contents up to and including the return path. At minimum this is a denial of service for any pipeline that inspects untrusted GeoTIFFs with listgeo; depending on mitigations it may also be exploitable for code execution.

8. Suggested fix

- In GTIFProj4AppendEllipsoid() (geotiff_proj4.c, the sprintf at line 47), stop appending with unbounded sprintf() into the caller's fixed buffer: either check the remaining space before formatting (and fail/clip safely) or switch the projection-string assembly to snprintf()/a growable string type.
- Apply the same hardening to the other two call sites of this helper: GTIFGetProj4Defn() at geotiff_proj4.c:1342 and GTIFProj4FromLatLong() at geotiff_proj4.c:1376, the latter appending into another fixed char szLongLat[256].
- Consider validating attacker-derived numeric expansions in general: the overflow is reached because "%.3f" of a crafted double expands to hundreds of characters.

9. Additional context

- Attachments: crash-input.bin (trigger sample) and negative-control.bin (benign EPSG:27563 file that only differs in the crafted fields) with their SHA256SUMS files.
- Prior related advisory: CVE-2014-8330 was a stack buffer overflow in the same listgeo tool, fixed in 1.4.1; the code path fixed for that advisory is a different site (geokey string copy), and this report concerns a distinct defect in the ellipsoid-string assembly of GTIFProj4ToLatLong()/GTIFProj4AppendEllipsoid().
- Environment note: the crash was observed and re-verified in an ASAN-instrumented Docker build of the project; the commands above reproduce it in any ASAN build of the same commit.

poc.zip