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