Thread: pg_dump: Fix dangling pointer in EndCompressorZstd()
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
Attachment
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
> 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
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
Attachment
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
> 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