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