[PATCH] Replace debug-only Asserts with runtime checks in logical replication apply worker
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
Attachments:
0001-Replace-debug-only-Asserts-with-runtime-checks-in-lo.patchapplication/octet-stream; name=0001-Replace-debug-only-Asserts-with-runtime-checks-in-lo.patchDownload+19-5
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.