From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Amul Sul <sulamul@gmail.com>, Sravan Kumar <sravanvcybage@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: pg_verifybackup: TAR format backup verification
In-reply-to: 
 <CA+TgmobHgpOnRSxJbWTVn9ZZ9SmoXxXw4-_R_ycEvOdJqKH0WA@mail.gmail.com>
References: 
 <CAAJ_b94StvLWrc_p4q-f7n3OPfr6GhL8_XuAg2aAaYZp1tF-nw@mail.gmail.com>
 <CA+=NbjjkFADANQoyvgTQfKH8ZerxpmsJD70R17V8ZtfaoyRYwg@mail.gmail.com>
 <CAAJ_b96xU5fOOvWhJyMvvDCirJEZZdjieZZbyf0PnYukFQCy+Q@mail.gmail.com>
 <CA+Tgmoa0FVRbC9EG5GDaXORqMsoj8AnEDV4FVXwbLENKqwQqaA@mail.gmail.com>
 <CAAJ_b96Gwh=6zwpqsD-sVNOeYcU=9rfBygVtuXmU3qFAiNr2Hw@mail.gmail.com>
 <CA+Tgmobmi7qiu8HDQECwuy-JrAH0zcYbzGnhnKjurqv44DHtxg@mail.gmail.com>
 <CAAJ_b94sxUN73kNZ_Z5sP0GDEZGAxKgW0PvS5CBJXiH212+Fww@mail.gmail.com>
 <CA+Tgmoboyugvh0C-QWfzQK0nNgOHrxGnQQiOROjaa--+Aqr2xg@mail.gmail.com>
 <CAAJ_b975Pyo53P-zvkTPjVFErEANuRP9+K=2Qnifiy6BJBtwfw@mail.gmail.com>
 <CA+Tgmobt6=v-jE4iJ2kBGQ=jfubX_7fdOe4Uf9TWhKn+cfjGfw@mail.gmail.com>
 <CAAJ_b95rXAsyuetre9Wc-W6uHW-=ivVj56F8-w4gfrTGsnRRSA@mail.gmail.com>
 <CA+TgmoZw9dc6w-FFFJvuFMEfB11c+tDRyW+BjWD89+NG8bV=iA@mail.gmail.com>
 <CAAJ_b95mcGjkfAf1qduOR97CokW8-_i-dWLm3v6x1w2-OW9M+A@mail.gmail.com>
 <CA+TgmoZTJzUyzDkdo6K7TTM2ePP0EMXTwxGhJN1Ymx3qNHvevQ@mail.gmail.com>
 <CA+TgmoYOQ!
 ex-MuAfh+Fe1dRKT+O=nH+fPYJ6bKpHfUxgZpumew@mail.gmail.com>
 <CA+TgmoZnG5DT1jo=9xgFztiLX4tU7+wr3D9HbhH_vPc+C5M0iA@mail.gmail.com>
 <CA+TgmoYkXG1mvc4kc=fid8Sn-k4M1a4T_m4nN1_1Ed9afKg2KQ@mail.gmail.com>
 <CAAJ_b95e9oNpQ+EdLgKX+aLJXwpWAy2EZsLBFSB9=XSPs4hhFg@mail.gmail.com>
 <CAAJ_b972EmWT+a63wtTAwfGF3QpYZkzwov5UPh=JPmgJY=dW8A@mail.gmail.com>
 <CA+TgmobUiaquaz7CTzDDpJu5e6XYuvxEc4e+HXEvUqn7PD4byw@mail.gmail.com>
 <CAAJ_b976LwbmzJLDLTw6ScAVbH7mtxWhj12MWtyRYSkCSjOcfw@mail.gmail.com>
 <CA+TgmoZ-fwQ0aWUs_40oXkEpF7JAn4D9SnKj8dj=qGLtO0VSRw@mail.gmail.com>
 <CA+Tgmobs-gbRUMGPpzVZnPPP=cgeEO7hnzV2yKmM0BQ=MGQSMg@mail.gmail.com>
 <CAAJ_b955y7NrkTUGtiyoGkPBs-OgYMv32iW0WTSpVfpFpezxdQ@mail.gmail.com>
 <CA+Tgmob3zhdDM=ggw-NrV-jrvLP7a-otWFn5F+5oOputiFdhmQ@mail.gmail.com>
 <CAAJ_b96RBwBMkgK3gzzm+94m6jvdbMi--8RzxaQLu-2+52Nj6g@mail.gmail.com>
 <CA+TgmoZBPKaonc=rE0d7YUm3fzeQTftP6o=8vqFDe1AY2nmbrw@mail.gmail.com>
 <1115881.1727564342@sss.pgh.pa.us> <1240823.1727629418@sss.pgh.pa.us>
 <CA+TgmobHgpOnRSxJbWTVn9ZZ9SmoXx!
 Xw4-_R_ycEvOdJqKH0WA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 30 Sep 2024 11:21:45 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1467227.1727710261.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 30 Sep 2024 11:31:01 -0400
Message-ID: <1467228.1727710261@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1467228.1727710261%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 29, 2024 at 1:03=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
>>> 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 poi=
nter "(char *)&mystreamer->control_file + mystreamer->control_file_bytes".

> I think this might be complaining about a potential zero-length copy.
> Seems like perhaps the <=3D 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