Horton

Thread

Commits

  1. pg_dump: Set private_date pointer to NULL in callback

  1. pg_dump: Fix dangling pointer in EndCompressorZstd()

    Alexander Kuznetsov <kuznetsovam@altlinux.org> — 2025-04-16T08:27:37Z

    Hello everyone,

We've found that EndCompressorZstd() doesn't set cs->private_data to NULL after pg_free(),
unlike other EndCompressor implementations.
While this doesn't currently cause issues (as the pointer soon gets reassigned),
we recommend fixing this to maintain consistency with other implementations and prevent potential future issues.

The patch is attached, would appreciate your thoughts on this change.

--
Best regards,
Alexander Kuznetsov

  2. Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-04-16T11:48:35Z

    On Wed, Apr 16, 2025 at 1:57 PM Alexander Kuznetsov
<kuznetsovam@altlinux.org> wrote:
>
> Hello everyone,
>
> We've found that EndCompressorZstd() doesn't set cs->private_data to NULL after pg_free(),
> unlike other EndCompressor implementations.
> While this doesn't currently cause issues (as the pointer soon gets reassigned),
> we recommend fixing this to maintain consistency with other implementations and prevent potential future issues.
>
> The patch is attached, would appreciate your thoughts on this change.

Thanks for the patch.

The next thing that happens in EndCompressor() is freeing cs itself.
So cs->private_data is not used anywhere, so no harm in the current
code. But it's better to set to NULL since EndCompressorZstd()
wouldn't know how it's being accessed after returning from there. The
other implementation of CompressionState::end() EndCompressorGzip()
calls DeflateCompressorEnd() which also sets cs->private_data
explicitly. So should EndCompressorZstd().

--
Best Wishes,
Ashutosh Bapat

  3. Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

    Daniel Gustafsson <daniel@yesql.se> — 2025-04-16T14:19:02Z

    > On 16 Apr 2025, at 13:48, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
> 
> On Wed, Apr 16, 2025 at 1:57 PM Alexander Kuznetsov
> <kuznetsovam@altlinux.org> wrote:
>> 
>> Hello everyone,
>> 
>> We've found that EndCompressorZstd() doesn't set cs->private_data to NULL after pg_free(),
>> unlike other EndCompressor implementations.
>> While this doesn't currently cause issues (as the pointer soon gets reassigned),
>> we recommend fixing this to maintain consistency with other implementations and prevent potential future issues.
>> 
>> The patch is attached, would appreciate your thoughts on this change.
> 
> Thanks for the patch.
> 
> The next thing that happens in EndCompressor() is freeing cs itself.
> So cs->private_data is not used anywhere, so no harm in the current
> code. But it's better to set to NULL since EndCompressorZstd()
> wouldn't know how it's being accessed after returning from there. The
> other implementation of CompressionState::end() EndCompressorGzip()
> calls DeflateCompressorEnd() which also sets cs->private_data
> explicitly. So should EndCompressorZstd().

Agreed, while it's perfectly safe today the end method should not make
assumptions about the use of the private_data pointer upon return and should
leave it set to NULL.

--
Daniel Gustafsson

  4. Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

    Michael Paquier <michael@paquier.xyz> — 2025-04-16T22:29:53Z

    On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
> Agreed, while it's perfectly safe today the end method should not make
> assumptions about the use of the private_data pointer upon return and should
> leave it set to NULL.

Indeed.  I was just looking at applying what Alexander has sent
because what EndCompressorZstd() not doing what the other methods do
makes no sense.  Perhaps you are already on it, Daniel?
--
Michael

  5. Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-04-16T23:12:52Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
>> Agreed, while it's perfectly safe today the end method should not make
>> assumptions about the use of the private_data pointer upon return and should
>> leave it set to NULL.

> Indeed.  I was just looking at applying what Alexander has sent
> because what EndCompressorZstd() not doing what the other methods do
> makes no sense.  Perhaps you are already on it, Daniel?

I think the actual reason for the difference is that the methods that
are taking care to zero the pointer do so because they test the
pointer themselves.  For instance in EndCompressorGzip, the test is
needed because perhaps no data was sent so the struct never got made.
It incidentally offers protection against a double call of that
function, but I don't think that was the intended reason.

I don't have any big objection to zeroing the pointer in
EndCompressorZstd, but I think the claim that it's precisely
analogous to the other EndCompressor methods is faulty,
because it has no similar test.

			regards, tom lane

  6. Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

    Daniel Gustafsson <daniel@yesql.se> — 2025-04-17T11:01:20Z

    > On 17 Apr 2025, at 01:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Michael Paquier <michael@paquier.xyz> writes:
>> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
>>> Agreed, while it's perfectly safe today the end method should not make
>>> assumptions about the use of the private_data pointer upon return and should
>>> leave it set to NULL.
> 
>> Indeed.  I was just looking at applying what Alexander has sent
>> because what EndCompressorZstd() not doing what the other methods do
>> makes no sense.  Perhaps you are already on it, Daniel?
> 
> I think the actual reason for the difference is that the methods that
> are taking care to zero the pointer do so because they test the
> pointer themselves.  For instance in EndCompressorGzip, the test is
> needed because perhaps no data was sent so the struct never got made.
> It incidentally offers protection against a double call of that
> function, but I don't think that was the intended reason.
> 
> I don't have any big objection to zeroing the pointer in
> EndCompressorZstd, but I think the claim that it's precisely
> analogous to the other EndCompressor methods is faulty,
> because it has no similar test.

Right, it has no similar test as the state in private_data is needed for both
read and write whereas gzip for example only need it for write (deflate).
Pushed as it improves code hygiene.

--
Daniel Gustafsson