Re: BUG #18925: Heap-buffer-overflow: pglz_compress with pglz_stategy_always

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, stasos24(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18925: Heap-buffer-overflow: pglz_compress with pglz_stategy_always
Date: 2025-05-31 23:46:25
Message-ID: 3020121.1748735185@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Daniel Gustafsson <daniel(at)yesql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-06-01 19:05:25 BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL
Previous Message David G. Johnston 2025-05-31 18:32:10 Re: [bug] keyword commit being accepted for column name