Re: Protect against possible memory corruption (src/backend/access/nbtree/nbtxlog.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Protect against possible memory corruption (src/backend/access/nbtree/nbtxlog.c)
Дата
Msg-id CAEudQArmWjGSki2pzja42SxDOdPUTyzzDnMNnbKEkS78W58uNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Protect against possible memory corruption (src/backend/access/nbtree/nbtxlog.c)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Protect against possible memory corruption (src/backend/access/nbtree/nbtxlog.c)
Список pgsql-hackers
Em dom., 11 de jul. de 2021 às 19:19, Heikki Linnakangas <hlinnaka@iki.fi> escreveu:
On 11/07/2021 22:51, Ranier Vilela wrote:
> Hi,
>
> While analyzing a possible use of an uninitialized variable, I checked that
> *_bt_restore_page* can lead to memory corruption,
> by not checking the maximum limit of array items which is
> MaxIndexTuplesPerPage.

> +     /* Protect against corrupted recovery file */
> +     nitems = (len / sizeof(IndexTupleData));
> +     if (nitems < 0 || nitems > MaxIndexTuplesPerPage)
> +             elog(PANIC, "_bt_restore_page: cannot restore %d items to page", nitems);
> +

That's not right. You don't get the number of items by dividing like
that. 'len' includes the tuple data as well, not just the IndexTupleData
header.
Thanks for the quick review.

Not totally wrong.
If it is not possible, know the upper limits, before the loop.
It is necessary to do this inside the loop.

attached v1 of patch.

regards,
Ranier Vilela
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Euler Taveira"
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: David Rowley
Дата:
Сообщение: Re: enable_resultcache confusion