Re: Use-after-free issue in postgres_fdw

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Use-after-free issue in postgres_fdw
Date: 2026-03-21 11:56:41
Message-ID: CAPmGK15_+6d4b6v0ALkjfXmiC7OKOXGr1xn3BTQEqFq9oJFhUQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 21, 2026 at 1:14 AM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> wrote:
> On 20/03/26 05:27, Chao Li wrote:
> > I am not very familiar with the FDW code, so I am not ready to suggest a concrete fix. But it seems wrong to let later paths keep using PgFdwScanState->conn after select * from ft1 has already failed with connection loss. My guess is that we either need to invalidate all dependent state when disconnect_pg_server() runs, or otherwise prevent later cleanup paths from touching the cached PGconn *.
>
> Although I agree with this I think that it will be a quite invasive
> change to fix this issue, considering that it should be back-ported.
>
> I see two ways to implement this:
>
> 1. ForeignScanState->conn points to a ConnCacheEntry and it access the
> PGConn via ConnCacheEntry->conn, so it can check if != NULL before using.
>
> 2. Make pgfdw_reject_incomplete_xact_state_change() or
> disconnect_pg_server() receive a PgFdwConnState and add a new field on
> this state to represent that the connection is closed and them check
> this field on the proper code paths.
>
> With the patch proposed on the previous email the server don't crash
> and any use of PgFdwScanState->conn will make the command to fail with
> something like this:
>
> ERROR: 08006: no connection to the server
> CONTEXT: remote SQL command: CLOSE c1
> LOCATION: pgfdw_report_internal, connection.c:1059
>
>
> So I don't think that this change would be worth, or I'm missing
> something? What do you think?

I don't feel the need to do these, either, for the reason mentioned upthread.

Thanks again!

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-03-21 12:21:49 Re: pg_waldump: support decoding of WAL inside tarfile
Previous Message Etsuro Fujita 2026-03-21 11:44:47 Re: Use-after-free issue in postgres_fdw