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-12 16:17:19
Message-ID: CAEudQAo3tGXP0Vm2X0q+rvuTOiAD3ntSNjPXzmef=b6k_ifvLA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg., 12 de jul. de 2021 às 05:20, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
escreveu:

> On 12/07/2021 02:34, Ranier Vilela wrote:
> > If it is not possible, know the upper limits, before the loop.
> > It is necessary to do this inside the loop.
>
> > @@ -49,10 +47,14 @@ _bt_restore_page(Page page, char *from, int len)
> > * To get the items back in the original order, we add them to the
> page in
> > * reverse. To figure out where one tuple ends and another
> begins, we
> > * have to scan them in forward order first.
> > + * Check the array upper limit to not overtake him.
> > */
> > i = 0;
> > - while (from < end)
> > + while (from < end && i <= MaxIndexTuplesPerPage)
> > {
> > + IndexTupleData itupdata;
> > + Size itemsz;
> > +
> > /*
> > * As we step through the items, 'from' won't always be
> properly
> > * aligned, so we need to use memcpy(). Further, we use
> Item (which
>
> If we bother checking it, we should throw an error if the check fails,
> not just silently soldier on. Also, shouldn't it be '<', not '<='?

Should be '<', you are right.

In
> general though, we don't do much checking on WAL records, we assume that
> the contents are sane. It would be nice to add more checks and make WAL
> redo routines more robust to corrupt records, but this seems like an odd
> place to start.
>
If WAL records can't be corrupted at _bt_restore_page, that's ok, it's safe.

> I committed the removal of bogus assignment to 'from'. Thanks!
>
Thanks for the commit.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2021-07-12 16:28:40 Re: PROXY protocol support
Previous Message vignesh C 2021-07-12 16:11:51 Re: proposal - psql - use pager for \watch command