Fix potential integer overflow in bringetbitmap()
authorMichael Paquier <michael@paquier.xyz>
Tue, 14 Jan 2025 06:13:19 +0000 (15:13 +0900)
committerMichael Paquier <michael@paquier.xyz>
Tue, 14 Jan 2025 06:13:19 +0000 (15:13 +0900)
This function expects an "int64" as result and stores the number of
pages to add to the index scan bitmap as an "int", multiplying its final
result by 10.  For a relation large enough, this can theoretically
overflow if counting more than (INT32_MAX / 10) pages, knowing that the
number of pages is upper-bounded by MaxBlockNumber.

To avoid the overflow, this commit redefines "totalpages", used to
calculate the result, to be an "int64" rather than an "int".

Reported-by: Evgeniy Gorbanyov
Author: James Hunter
Discussion: https://www.postgresql.org/message-id/07704817-6fa0-460c-b1cf-cd18f7647041@basealt.ru
Backpatch-through: 13

src/backend/access/brin/brin.c

index 8c6ee96ca81cc0cbdf04e36f4aa444b9f39d3b2b..179b7dfa45665cde1de87fcb6bfd6cc33be48b0a 100644 (file)
@@ -361,7 +361,7 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
    BrinOpaque *opaque;
    BlockNumber nblocks;
    BlockNumber heapBlk;
-   int         totalpages = 0;
+   int64       totalpages = 0;
    FmgrInfo   *consistentFn;
    MemoryContext oldcxt;
    MemoryContext perRangeCxt;