Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Ethan Mertz <ethan(dot)mertz(at)gmail(dot)com>
Subject: Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT
Date: 2025-08-01 04:33:14
Message-ID: CAA4eK1L8x5CgzShZ2FLW0QLUVqQZxjp9MLpeFbHBqUeN++VEDA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 31, 2025 at 12:14 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Ethan Mertz (colleague, in CC) has found a bug in reorderbuffer.c when
> processing a REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM change, based
> on the data gathered from a customer issue. The bug is a
> use-after-free, causing random crashes, that can be summarized like
> that:
...
>
> A simple solution suggested by Ethan would be to use the "prev_lsn"
> guessed from the change at the beginning of the loop, rather than the
> problematic change->lsn. But that does not seem completely right to
> me because we can switch to "specinsert" as the change to process,
> hence wouldn't we want to call update_progress_txn() based on the LSN
> of the actual change we are looking at?
>

We still won't be able to capture the latest LSN in case of
REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT. IIRC, update_progress_txn
is used to keep the client active so that when many changes are
skipped, the client doesn't timeout. In this case, it seems okay to
use prev_lsn as well.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tender Wang 2025-08-01 04:38:00 Re: BUG #19000: gist index returns inconsistent result with gist_inet_ops
Previous Message Alexandra Wang 2025-08-01 03:50:42 Re: BUG #16961: Could not access status of transaction