From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: Dilip Kumar <dilipbalaut@gmail.com>, stasos24@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18925: Heap-buffer-overflow: pglz_compress with
 pglz_stategy_always
In-reply-to: <CA3905AE-1AC0-42FF-937E-7E4895DB163F@yesql.se>
References: <18925-3b7ab7c50b77c53d@postgresql.org>
 <CAFiTN-sSx4Xx=0bm4D_hfSs5XUtNs25T6SBeiCnn4xiFVK_scg@mail.gmail.com>
 <CA3905AE-1AC0-42FF-937E-7E4895DB163F@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Wed, 14 May 2025 15:35:08 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3020120.1748735185.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 31 May 2025 19:46:25 -0400
Message-ID: <3020121.1748735185@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3020121.1748735185%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
> The way I read it there is now way to reproduce this as the codepath use=
d in
> the fuzzer ins't present in postgres (PGLZ_strategy_always is not used b=
y 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