agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c 6+ messages / 1 participants [nested] [flat]
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dc3db3a8349bd164354ef5b6c94d1c0c2adc651c Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/15f4e3d0ce92474220fcc83f789c45051c77da0f Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/59759e1a5b499294d73d409e0bc3343aafd2973f Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/871d4f5b640c83a2644a389db8d1bf1bd6a29382 Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c @ 2026-05-17 01:03 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 6+ messages in thread From: Noah Misch @ 2026-05-17 01:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/510a05f07cb5ff86fbbedac848ee5c80b8bbfd83 Modified Files -------------- src/backend/replication/logical/worker.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-17 01:03 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com> 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com> 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com> 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com> 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com> 2026-05-17 01:03 pgsql: Use ereport(ERROR), not Assert(), for publisher tuples missing c Noah Misch <noah@leadboat.com>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox