Re: Avoid an odd undefined behavior with memcmp (src/bin/pg_rewind/pg_rewind.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Avoid an odd undefined behavior with memcmp (src/bin/pg_rewind/pg_rewind.c)
Date
Msg-id CAEudQAqtM3k9EHuYjg8_gtd7=jroxuZXh9Hj2oNaLkq=a2_VXw@mail.gmail.com
Whole thread Raw
In response to Re:Avoid an odd undefined behavior with memcmp (src/bin/pg_rewind/pg_rewind.c)  ("Long Song" <songlong88@126.com>)
List pgsql-hackers
Em qua., 29 de mai. de 2024 às 22:41, Long Song <songlong88@126.com> escreveu:

Hi Ranier,



> IMO, I think that pg_rewind can have a security issue,
> if two files are exactly the same, they are considered different.
> Because use of structs with padding values is unspecified.
Logically you are right. But I don't understand what scenario
would require memcmp to compare ControlFileData.
In general, we read ControlFileData from a pg_control file
and then use members of ControlFileData directly.
So the two ControlFileData are not directly compared by byte.
Actually in pg_rewind there is a comparison using memcmp.
 

> Fix by explicitly initializing with memset to avoid this.
And, even if there are scenarios that use memcmp comparisons,
your modifications are not complete.
There are three calls to the digestControlFile in the main()
of pg_rewind.c, and as your said(if right), these should do
memory initialization every time.
In fact, initializing structures with memset does not solve anything.
Once the entire structure is populated again by a call to memcpy shortly thereafter.
My concern now is that when the structure is saved to disk, 
what are the padding fields like?

But enough noise.
Thanks for taking a look.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Fix possible dereference null pointer (PQprint)
Next
From: Peter Eisentraut
Date:
Subject: Re: pgsql: Add more SQL/JSON constructor functions