]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Use ereport(ERROR), not Assert(), for publisher tuples missing columns.
authorNoah Misch <noah@leadboat.com>
Sun, 17 May 2026 01:01:35 +0000 (18:01 -0700)
committerNoah Misch <noah@leadboat.com>
Sun, 17 May 2026 01:01:40 +0000 (18:01 -0700)
commit871d4f5b640c83a2644a389db8d1bf1bd6a29382
tree2718634304307cbb55c0b6ddb03fb953a6ef0a5d
parent2a975b991e44ec6b3ac39612869176fdbd3c0db2
Use ereport(ERROR), not Assert(), for publisher tuples missing columns.

Three locations use Assert() to guard against a mismatch between the
number of columns advertised in the RELATION message and the number
actually received in the subsequent INSERT/UPDATE tuple message. Since
these values originate from the publisher, the check must survive into
production builds.

A malicious or buggy publisher can send a RELATION claiming N columns
and an INSERT claiming M < N columns. The subscriber's apply worker
indexes into colvalues[]/colstatus[] using column indices from the
RELATION message's attribute map, causing a heap out-of-bounds read when
the tuple's column array is smaller than expected. We've looked, without
success, for a scenario in which the publisher holds sufficient control
over these out-of-bounds bytes to exploit this or even to reach a
SIGSEGV. Despite not finding one, the code has been fragile. Back-patch
to v14 (all supported versions).

Reported-by: Varik Matevosyan <varikmatevosyan@gmail.com>
Author: Varik Matevosyan <varikmatevosyan@gmail.com>
Discussion: https://postgr.es/m/CA+bBoog3cCogktzfLb9bppUByu-10B3CFp8u=iKXG_OvtAguCw@mail.gmail.com
Backpatch-through: 14
src/backend/replication/logical/worker.c