Re: Avoid possible overflow (src/port/bsearch_arg.c)
От | Tomas Vondra |
---|---|
Тема | Re: Avoid possible overflow (src/port/bsearch_arg.c) |
Дата | |
Msg-id | 54ee5b1f-bf75-48ea-b642-1ef275c1a093@vondra.me обсуждение исходный текст |
Ответ на | Re: Avoid possible overflow (src/port/bsearch_arg.c) (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Avoid possible overflow (src/port/bsearch_arg.c)
|
Список | pgsql-hackers |
On 10/28/24 13:13, Heikki Linnakangas wrote: > On 09/10/2024 19:16, Ranier Vilela wrote: >> Em ter., 8 de out. de 2024 às 18:28, Nathan Bossart >> <nathandbossart@gmail.com <mailto:nathandbossart@gmail.com>> escreveu: >> >> 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. >> >> Thanks for looking. > > Committed, thanks. > > Based on the original discussion on bfa2cee, I couldn't figure out where > exactly this new bsearch implementation originated from, but googling > around, probably *BSD or libiberty. Tomas, do you remember? Not that it > matters, but I'm curious. > I don't remember, unfortunately :-( I think it was one of the *BSDs, because of license, but I'm not quite sure why I changed the code at all during the move. > Some of those other implementations have fixed this, others have not. > And they all seem to also have the "involes" typo in the comment that we > fixed in commit 7ef8b52cf07 :-). Ranier, you might want to submit this > fix to those other projects too. > Thanks for fixing this, although I wonder if we can actually hit this, as we don't really allocate more than 1GB in most places. But it's possible, and the pre-bfa2cee code handled it fine. regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления: