Fix potential integer overflow in bringetbitmap()
authorMichael Paquier <michael@paquier.xyz>
Tue, 14 Jan 2025 06:13:15 +0000 (15:13 +0900)
committerMichael Paquier <michael@paquier.xyz>
Tue, 14 Jan 2025 06:13:15 +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 a257903991d4d1916d77872648c674cce6041e9c..d69d0fdf09a143717fd96ad70cfa00ac6742acec 100644 (file)
@@ -363,7 +363,7 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
    BrinOpaque *opaque;
    BlockNumber nblocks;
    BlockNumber heapBlk;
-   int         totalpages = 0;
+   int64       totalpages = 0;
    FmgrInfo   *consistentFn;
    MemoryContext oldcxt;
    MemoryContext perRangeCxt;