[VRT] [PATCH] VRTDerivedRasterBand with ComplexSource and nodata value yields potentially uninitialized buffer

[bclaywell]

(This bug was observed in 1.8.0 but it looks like the affected code is still the same in trunk, so the traclinks below go to trunk.)

VRTComplexSource::RasterIO appears to expect that the buffer pointed to by its pData argument has already been initialized with zero or a nodata value by its caller, as the per-pixel loop simply skips to the next pixel if a nodata value is encountered, as seen here.

When VRTComplexSource::RasterIO is called by VRTSourcedRasterBand::IRasterIO, this is not a problem, as the buffer is correctly initialized with zeroes or nodata, starting here.

However, VRTDerivedRasterBand::IRasterIO does *not* initialize its buffers before calling out to the individual sources to populate those buffers; see here. The buffers are simply malloc'd and then immediately passed to VRTSource::RasterIO to be populated, with no initialization.

In other words, any pixel in the source image that equals the ComplexSource's nodata value will never be initialized and will instead contain whatever garbage happened to be at those locations in memory.

[bclaywell]

I've attached a patch that resolves the issue by initializing the source buffers to zero or nodata inside VRTDerivedRasterBand::IRasterIO. Let me know if that's not the philosophically "right" thing to do, i.e. if it would be better if the VRTSources initialized their own buffers or something like that.

[Even Rouault]

r22324 /trunk/gdal/frmts/vrt/vrtderivedrasterband.cpp: Fix 'VRTDerivedRasterBand with ComplexSource and nodata value yields potentially uninitialized buffer' (#4045)

[Even Rouault]

r22441 /branches/1.8/gdal/frmts/vrt/vrtderivedrasterband.cpp: Fix 'VRTDerivedRasterBand with ComplexSource and nodata value yields potentially uninitialized buffer' (#4045)