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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
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 08:20:57
Message-ID: 50678df4-4f70-4308-5028-71af9bbc678e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 '<='? 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.

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

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-07-12 08:25:07 Re: Can a child process detect postmaster death when in pg_usleep?
Previous Message houzj.fnst@fujitsu.com 2021-07-12 08:00:52 RE: Parallel INSERT SELECT take 2