Thread

Re: [PATCH] Fix use-after-free of propgraph orphan static lists on xact abort

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-13T06:50:49Z

On Tue, May 12, 2026 at 11:23 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> Hi hackers,
>
> My PG19 fuzz tests detected the $subject issue in dependency.c.
>
> Repro: It is not 100% deterministic because of the timeout, if hard to follow can write
> an injection point test.
>
> \set ON_ERROR_STOP off
>
> CREATE TABLE n1(id int PRIMARY KEY, name text);
>
> -- Many indexes ensure the cascade takes enough time after the propgraph
> -- element's deleteOneObject() for statement_timeout to fire.
> DO $$ BEGIN
>   FOR i IN 1..50 LOOP
>     EXECUTE format('CREATE INDEX idx_%s ON n1 (id) WHERE id > %s', i, i);
>   END LOOP;
> END $$;
> CREATE PROPERTY GRAPH pg1 VERTEX TABLES (n1 LABEL l1 PROPERTIES(id, name));
>
> CREATE TABLE n2(id int PRIMARY KEY, name text);
> CREATE PROPERTY GRAPH pg2 VERTEX TABLES (n2 LABEL l2 PROPERTIES(id, name));
>
> SET statement_timeout = '3ms';
> DROP TABLE n1 CASCADE;
> RESET statement_timeout;
>
> DROP TABLE n2 CASCADE;
>
> SELECT 1 AS status;
>
> The static lists propgraph_orphan_label_graphids and propgraph_orphan_property_graphids
> in dependency.c are allocated in TopTransactionContext during deleteOneObject().  They are
> only reset on the success path of performDeletion()/performMultipleDeletions(), in
> run_deferred_propgraph_orphan_cleanup(). If a transaction aborts after the lists have been
> populated, for example due to statement_timeout, or any other error thrown during the cascade),
> AbortTransaction() frees TopTransactionContext but the static pointers remain set.  A subsequent
> property graph cascade in the same backend session then passes the dangling pointers to
> list_append_unique_oid(), which walks freed memory.  With assertions enabled this trips
>
>   TRAP: failed Assert("IsOidList(list)"), File: "list.c", Line: 726
>

I am not able to find any of the variables mentioned in the above
paragraph in dependency.c. Am I missing something? My branch's HEAD is
pointing at 422e54e3092afd09997d27cc7c99598f91075b0d. Patch doesn't
apply. Am I missing something?

-- 
Best Wishes,
Ashutosh Bapat