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 <[email protected]> Author: Varik Matevosyan <[email protected]> Discussion: https://postgr.es/m/CA+bBoog3cCogktzfLb9bppUByu-10B3CFp8u=ikxg_ovtag...@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bf7d19be9b18f6f78bd95052a2704259021e6806 Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
