Daniel Gustafsson <daniel@yesql.se> writes:
> The way I read it there is now way to reproduce this as the codepath used in
> the fuzzer ins't present in postgres (PGLZ_strategy_always is not used by any
> callsite).
> Whether or not there is a bug in the compression code, or PGLZ_strategy_always
> being incorrectly defined, or none of the above, remains to be seen.
I think the bug is in the test program: it's allocating an output
buffer of the same size as the input buffer. This does not conform
to the API spec for pglz_compress:
* int32
* pglz_compress(const char *source, int32 slen, char *dest,
* const PGLZ_Strategy *strategy);
*
* source is the input data to be compressed.
*
* slen is the length of the input data.
*
* dest is the output area for the compressed result.
* It must be at least as big as PGLZ_MAX_OUTPUT(slen).
PGLZ_MAX_OUTPUT adds 4 bytes to the size, which the test program
is not doing, so an output buffer overrun can be expected
no matter which strategy is selected.
regards, tom lane