| 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
| 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 |