[PATCH] pageinspect: validate line pointers before using them

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: [PATCH] pageinspect: validate line pointers before using them
Date: 2026-08-31 03:48:45
Message-ID: CAGRkXqRWDJR7Ma=589-cOFaOK2pG-XxUgXzYvje9eMxxSiOm8g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

While reading contrib/pageinspect I noticed that the GiST, B-tree and
hash page_items() functions can read past the page image when handed a
corrupt or crafted page. The attached patch fixes it and adds regression
tests;

The only check they do before following a line pointer is
ItemIdIsValid(), but that just tests the pointer isn't NULL -- and it
never is. So a bogus line pointer offset makes the code read outside the
page image. heap_page_items() already guards against this; the attached
patch does the same for these three functions and adds regression tests.

Easy to see on an AddressSanitizer build:
CREATE EXTENSION pageinspect;
CREATE TABLE t AS SELECT point(i,i) p FROM generate_series(1,1000) i;
CREATE INDEX t_idx ON t USING gist (p);
-- overwrite the first line pointer with garbage:
SELECT gist_page_items_bytea(
set_byte(set_byte(set_byte(set_byte(
get_raw_page('t_idx', 0), 24, 255), 25, 255), 26, 255), 27, 255));
Without the patch this trips ASan (heap-buffer-overflow in
gist_page_items_bytea) and the backend goes down. With it, you just get:
ERROR: invalid line pointer at offset 1 in GiST page
These functions are superuser-only, so it's about not crashing on a
corrupt page rather than a security issue.

Thanks,
Shihao

Attachment Content-Type Size
0001-pageinspect-validate-line-pointers-before-using-them.patch application/octet-stream 10.0 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-31 04:27:55 Re: [PATCH] Add tests for src/backend/nodes/extensible.c
Previous Message Zhijie Hou (Fujitsu) 2026-08-31 03:15:19 RE: Logical replication row filter loses unchanged toasted columns