From: | James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com> |
---|---|
To: | Evgeniy Gorbanyov <gorbanyoves(at)basealt(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Possible integer overflow in bringetbitmap() |
Date: | 2024-12-04 22:05:10 |
Message-ID: | CAJVSvF4V4BvH9uh5PjJ9Oux4qVcreG5vLxTK4vu_ef0Bq8effg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 26, 2024 at 2:57 AM Evgeniy Gorbanyov
<gorbanyoves(at)basealt(dot)ru> wrote:
>
> Function bringetbitmap() in src/backend/access/brin/brin.c:560 returns type int64. But the returned variable 'totalpages' is of type int. Maybe it makes sense to change the type of variable 'totalpages' to int64 to avoid possible overflow in expression 'totalpages * 10'?
It looks to me like "totalpages" can never be larger than "nblocks",
which is of type BlockNumber, an alias for uint32.
The reason the function returns int64 is because it multiplies
"totalpages" by 10. However, notice that the existing line:
return totalpages * 10;
-- doesn't cast either "totalpages" or "10" to "int64", so the result
is of type uint32 again, which leads to integer overflow.
So, I think your patch should be, instead, to cast either "totalpages"
or "10" to "int64", in the return statement.
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2024-12-04 22:11:31 | Re: SCRAM pass-through authentication for postgres_fdw |
Previous Message | Thomas Munro | 2024-12-04 21:58:19 | Re: Cannot find a working 64-bit integer type on Illumos |