Re: Assert in pageinspect with NULL pages - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Assert in pageinspect with NULL pages
Date
Msg-id YjrXaecdozs6EzYe@paquier.xyz
Whole thread Raw
In response to Re: Assert in pageinspect with NULL pages  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Assert in pageinspect with NULL pages  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Fri, Mar 18, 2022 at 06:43:39AM +0300, Alexander Lakhin wrote:
> Hello Michael,
> No, just x86_64, Ubuntu 20.04, gcc 11, valgrind 3.15. I just put that query
> in page.sql and see the server abort.

Bah, of course, I have missed the valgrind part of the problem.

The problem is that we attempt to verify a heap page here but its
pd_special is BLCKSZ.  This causes BrinPageType() to grab back a
position of the area at the exact end of the page, via
PageGetSpecialPointer(), hence the failure in reading two bytes
outside the page.  The result here is that the set of defenses in
verify_brin_page() is poor: we should at least make sure that the
special area is available for a read.  As far as I can see, this is
also possible in bt_page_items_bytea(), gist_page_opaque_info(),
gin_metapage_info() and gin_page_opaque_info().  All those code paths
should be protected with some checks on PageGetSpecialSize(), I
guess, before attempting to read the special area of the page.  Hash
indexes are protected by checking the expected size of the special
area, and one code path of btree relies on the opened relation to be a
btree index.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: shared-memory based stats collector - v67
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: shared-memory based stats collector - v67