Re: pg_verifybackup: TAR format backup verification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_verifybackup: TAR format backup verification
Date
Msg-id 1467228.1727710261@sss.pgh.pa.us
Whole thread Raw
In response to pg_verifybackup: TAR format backup verification  (Amul Sul <sulamul@gmail.com>)
Responses Re: pg_verifybackup: TAR format backup verification
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 29, 2024 at 1:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> CID 1620458:  Resource leaks  (RESOURCE_LEAK)
>>> Variable "buffer" going out of scope leaks the storage it points to.

> This looks like a real leak. It can only happen once per tarfile when
> verifying a tar backup so it can never add up to much, but it makes
> sense to fix it.

+1

>>> CID 1620457:  Memory - illegal accesses  (OVERRUN)
>>> Overrunning array of 296 bytes at byte offset 296 by dereferencing pointer "(char *)&mystreamer->control_file +
mystreamer->control_file_bytes".

> I think this might be complaining about a potential zero-length copy.
> Seems like perhaps the <= sizeof(ControlFileData) test should actually
> be < sizeof(ControlFileData).

That's clearly an improvement, but I was wondering if we should also
change "len" and "remaining" to be unsigned (probably size_t).
Coverity might be unhappy about the off-the-end array reference,
but perhaps it's also concerned about what happens if len is negative.

>>> CID 1620456:  Null pointer dereferences  (FORWARD_NULL)
>>> Passing null pointer "suffix" to "strcmp", which dereferences it.

> This one is happening, I believe, because report_backup_error()
> doesn't perform a non-local exit, but we have a bit of code here that
> acts like it does.

Check.

> Patch attached.

WFM, modulo the suggestion about changing data types.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_verifybackup: TAR format backup verification
Next
From: Tom Lane
Date:
Subject: Re: ACL_MAINTAIN, Lack of comment content