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_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0bffea8f6030c5a5d11e5fda42f2bf9264a54ccf Modified Files -------------- src/bin/pg_combinebackup/reconstruct.c | 6 ++++++ 1 file changed, 6 insertions(+)
