Critical Buffer Overflow in GDAL Arc/Info Grid Driver Enables Code Execution via Crafted Files

A stack-buffer-overflow vulnerability has been identified in GDAL's Arc/Info Binary Grid (AIG) raster driver, specifically in the `DecompressCCITTRLETile` function located in `aigccitt.c`. The vulnerability stems from a fundamental flaw in a size validation check: the function declares a 4000-byte stack buffer (`runs_buf[4000]`) intended to hold `GUInt32` run-length entries, yet the guard check `sizeof(runs_buf) < (size_t)(nBlockXSize * 2 + 3)` compares the byte size of the buffer against a count of array elements rather than their actual byte footprint. This makes the protection ineffective by a factor of four, allowing an attacker-supplied AIG file with `nBlockXSize = 1998` to bypass validation—passing the check as `4000 < 3999`—while the CCITT-RLE Fax3 decoder subsequently writes 3999 `GUInt32` entries, requiring 15,996 bytes into the 4,000-byte stack allocation. The resulting overflow reaches 11,996 bytes of uncontrolled data on the call stack.

The attack vector is straightforward: any application that processes untrusted AIG files through GDAL becomes a potential target. This includes GIS software, geospatial data processing pipelines, image conversion tools, and cloud services handling legacy geospatial formats. The vulnerability carries severe implications—successful exploitation enables arbitrary code execution within the context of the vulnerable application, while even failed attempts result in a reliable denial-of-service condition through a crash. This places it among the most critical vulnerability classes for parsers handling external input.

The underlying cause is a straightforward but dangerous type mismatch in the bounds check. Developers performing security audits of geospatial libraries or data ingestion systems should flag GDAL AIG file processing for immediate review. Organizations accepting AIG datasets from external sources should treat them as untrusted input requiring sandboxing or validation. The vulnerability highlights the ongoing risk of subtle integer arithmetic errors in bounds validation logic, where off-by-factor mistakes render protective checks completely ineffective despite appearing reasonable at first glance.