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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protect against possible memory corruption (src/backend/access/nbtree/nbtxlog.c)
Date: 2021-07-11 23:34:15
Message-ID: CAEudQArmWjGSki2pzja42SxDOdPUTyzzDnMNnbKEkS78W58uNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em dom., 11 de jul. de 2021 às 19:19, Heikki Linnakangas <hlinnaka(at)iki(dot)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

Attachment Content-Type Size
v1-0001-_bt_restore_page-have-issues-can-lead-a-memory-co.patch application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-07-11 23:47:27 Re: enable_resultcache confusion
Previous Message Euler Taveira 2021-07-11 23:30:24 Re: row filtering for logical replication