Re: pg_verifybackup: TAR format backup verification
От | Tom Lane |
---|---|
Тема | Re: pg_verifybackup: TAR format backup verification |
Дата | |
Msg-id | 1467228.1727710261@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_verifybackup: TAR format backup verification (Amul Sul <sulamul@gmail.com>) |
Ответы |
Re: pg_verifybackup: TAR format backup verification
|
Список | 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 по дате отправления: