Re: Possible integer overflow in bringetbitmap()

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.

In response to

Responses

Browse pgsql-hackers by date

  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