Date: Tue, 8 Oct 2024 16:28:37 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Avoid possible overflow (src/port/bsearch_arg.c)
Message-ID: <ZwWkBb2gxs5fGttK@nathan>
References: <CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi+w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZwWkBb2gxs5fGttK%40nathan>
Precedence: bulk

On Tue, Oct 08, 2024 at 04:09:00PM -0300, Ranier Vilela wrote:
> The port function *bsearch_arg* mimics the C function
> *bsearch*.
> 
> The API signature is:
> void *
> bsearch_arg(const void *key, const void *base0,
> size_t nmemb, size_t size,
> int (*compar) (const void *, const void *, void *),
> void *arg)
> 
> So, the parameter *nmemb* is size_t.
> Therefore, a call with nmemb greater than INT_MAX is possible.
> 
> Internally the code uses the *int* type to iterate through the number of
> members, which makes overflow possible.

I traced this back to commit bfa2cee (v14), which both moved bsearch_arg()
to its current location and adjusted the style a bit.  Your patch looks
reasonable to me.

-- 
nathan