CFE_FS_Decompress infinite loop on truncated gzip file

[skliper]

If CFS_FS_Decompress is given a truncated gzip file, it will enter an infinite loop in which it attempts to read more data from the file, gets nothing, and tries again. Discovered by accidentally attempting to have ES load a new compressed application (which we didn't know had been truncated), which led to ES getting stuck and an eventual watchdog reset.

The problem seems to be that running out of bytes in a gzipped file before decompression is finished is not considered an error. I can see how this might be intentional if it is expected that the file handle might be a stream that could present data after being emptied, but for the normal file use case I think it is a bug. Suggested fix by combining the two checks at line 309 of cfe_fs_decompress.c:

if ( State->insize == 0 ) return EOF;

if ( len == OS_FS_ERROR )
{
State->Error = CFE_FS_GZIP_READ_ERROR;
return EOF;
}

into one:

if ((State->insize == 0) !|| (len == OS_FS_ERROR)) {
State->Error = CFE_FS_GZIP_READ_ERROR;
return EOF;
}

Recommend investigation if insize might temporarily hit 0 during a normal decompression.

Reported via email from Mike Stewart, [email protected]

[skliper]

Imported from trac issue 267. Created by jhageman on 2019-03-26T11:07:06, last modified: 2019-07-03T12:48:08

[skliper]

Trac comment by jhageman on 2019-07-03 12:48:08:

Moved unfinished 6.6.1 issues to next minor release

[thewonderidiot]

Hi, Mike here! I can't send the file that originally caused this problem for us (EAR...) but I've made another one that causes the same issue. Starting with this image:

If I compress and the truncate the image as follows:

gzip corgi.jpg
dd if=corgi.jpg.gz of=corgi2.jpg.gz bs=2048 count=1

This gives me this file: corgi2.jpg.gz

If I uplink this to our flight computer and then try to extract it via FM_DECOMPRESS, ES_START_APP, etc., whatever app tries to do the decompression gets stuck in an infinite loop.

Let me know if this file is able to reproduce it for you!

[skliper]

Edit... fixed in #367