Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: kuznetsovam(at)altlinux(dot)org
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, egori(at)altlinux(dot)org, nickel(at)altlinux(dot)org
Subject: Re: pg_dump: Fix dangling pointer in EndCompressorZstd()
Date: 2025-04-16 11:48:35
Message-ID: CAExHW5uEAPLhaawqjZOU+yGjS1h8L_U0QGvrx+xA0Y3gF3hdSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 16, 2025 at 1:57 PM Alexander Kuznetsov
<kuznetsovam(at)altlinux(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2025-04-16 12:11:45 Re: not null constraints, again
Previous Message Alvaro Herrera 2025-04-16 11:24:13 Re: not null constraints, again