Date: Sat, 16 May 2026 18:40:54 -0700
From: Noah Misch <noah@leadboat.com>
To: Varik Matevosyan <varikmatevosyan@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: [PATCH] Replace debug-only Asserts with runtime checks in
 logical replication apply worker
Message-ID: <20260517014054.c1@rfd.leadboat.com>
References: 
 <CA+bBoog3cCogktzfLb9bppUByu-10B3CFp8u=iKXG_OvtAguCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+bBoog3cCogktzfLb9bppUByu-10B3CFp8u=iKXG_OvtAguCw@mail.gmail.com>
User-Agent: Mutt/2.3.0 (2026-01-25)
Archived-At: 
 <https://www.postgresql.org/message-id/20260517014054.c1%40rfd.leadboat.com>
Precedence: bulk

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.