Fix potential integer overflow in bringetbitmap()
authorMichael Paquier <[email protected]>
Tue, 14 Jan 2025 06:12:56 +0000 (15:12 +0900)
committerMichael Paquier <[email protected]>
Tue, 14 Jan 2025 06:12:56 +0000 (15:12 +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 9a98454757897c84b3519ab020e762855eb8df7e..4289142e20b6f006fbf2c1f574cf7a094d66a526 100644 (file)
@@ -567,7 +567,7 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
    BrinOpaque *opaque;
    BlockNumber nblocks;
    BlockNumber heapBlk;
-   int         totalpages = 0;
+   int64       totalpages = 0;
    FmgrInfo   *consistentFn;
    MemoryContext oldcxt;
    MemoryContext perRangeCxt;