pg_combinebackup: Reject out-of-range block numbers in incremental files The header of an incremental file was only partially validated: num_blocks and truncation_block_length were checked against RELSEG_SIZE, but the block numbers stored after them were not checked at all. A block number of 0xFFFFFFFF made find_reconstructed_block_length() compute a reconstructed length of zero, since it adds 1 to the block number in 32-bit arithmetic, and reconstruct_from_incremental_file() then allocated zero-length sourcemap and offsetmap arrays but still indexed them with the block numbers taken from the file. In an assertions-enabled build, this would be caught by an Assert, but otherwise it would index the arrays out of bounds, typically crashing the process.
To fix, check the block numbers when the header is read, like the other header fields. Reported-by: Sajeeb Lohani working with TrendAI Zero Day Initiative Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/48a1c38e8cb6dc4e61626c2119f914cf17c39550 Modified Files -------------- src/bin/pg_combinebackup/reconstruct.c | 6 ++++++ 1 file changed, 6 insertions(+)
