Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use ereport(ERROR), not Assert(), for publisher tuples missing columns.

  1. [PATCH] Replace debug-only Asserts with runtime checks in logical replication apply worker

    Varik Matevosyan <varikmatevosyan@gmail.com> — 2026-05-16T22:30:00Z

    The attached patch replaces three debug-only Asserts with runtime
ereport(ERROR, ERRCODE_PROTOCOL_VIOLATION) checks in the logical
replication apply worker (worker.c). These guard against a mismatch
between the column count in the RELATION message and the count in a
subsequent INSERT/UPDATE/DELETE tuple message.

A publisher can send a RELATION claiming N columns and
an INSERT claiming M < N columns, causing the subscriber
to index past the end of the tuple's colvalues[]/colstatus[] arrays.

I believe this is more of a correctness fix than a security issue as
the attacker needs replication privileges, and in my testing I was not
able to trigger a SIGSEGV, the OOB read landed on heap bytes that
happened to not cause a crash.

P.S: After a security review from Noah, I'm reporting this as a bug.

Thanks,
Varik

  2. Re: [PATCH] Replace debug-only Asserts with runtime checks in logical replication apply worker

    Noah Misch <noah@leadboat.com> — 2026-05-17T01:40:54Z

    On Sun, May 17, 2026 at 02:30:00AM +0400, Varik Matevosyan wrote:
> The attached patch replaces three debug-only Asserts with runtime
> ereport(ERROR, ERRCODE_PROTOCOL_VIOLATION) checks in the logical
> replication apply worker (worker.c). These guard against a mismatch
> between the column count in the RELATION message and the count in a
> subsequent INSERT/UPDATE/DELETE tuple message.
> 
> A publisher can send a RELATION claiming N columns and
> an INSERT claiming M < N columns, causing the subscriber
> to index past the end of the tuple's colvalues[]/colstatus[] arrays.
> 
> I believe this is more of a correctness fix than a security issue as
> the attacker needs replication privileges, and in my testing I was not
> able to trigger a SIGSEGV, the OOB read landed on heap bytes that
> happened to not cause a crash.
> 
> P.S: After a security review from Noah, I'm reporting this as a bug.

Pushed (bf7d19b).  Thank you.