Re: [PATCH v1 0/3] Route crypto through the OpenSSL 3 provider API

Re: [PATCH v1 0/3] Route crypto through the OpenSSL 3 provider API

On Tue, Aug 04, 2026 at 05:48:02PM -0700, Mark Atwood wrote:
> When built against OpenSSL 3.0 or newer, PostgreSQL's OpenSSL crypto backend
> still uses pre-3.0 interfaces that do not go through the provider framework,
> so a loaded provider's implementation is not used:
> 
>   - HMAC uses HMAC_CTX / HMAC_Init_ex, deprecated since 3.0;
>   - cryptohash and channel binding initialize the digest with the implicit
>     static MDs (EVP_sha256() etc.).

Please note patches should be attached to the emails sent to the
community mailing lists.  We do not use commands like `git send-mail`.

FYI, I am interested in what you are doing here for the HMAC and
channel binding parts, at least, having committed the code we have in
the tree and that you are updating here.  Just make sure to begin one
thread for each patch proposed, with the patch attached, so as we are
able to discuss and review each item separately.  Generating the
patches with format-patch is a common practice.

Please see also:
https://wiki.postgresql.org/wiki/Submitting_a_Patch#Patch_submission

Thanks,
--
Michael

Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection

Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection

On Fri, Jun 5, 2026 at 7:55 PM Amjad Shahzad  wrote:
>
> Hi Fujii,
>
> You are correct. I checked the libpq source and both PQconsumeInput() and PQnotifies() have explicit NULL guards:
>
>     /* fe-exec.c line 2003 */
>     if (!conn)
>         return 0;
>
>     /* fe-exec.c line 2688 */
>     if (!conn)
>         return NULL;
>
> So no segmentation fault actually occurs. The function silently returns 0 rows when called without a prior connection instead of crashing.
>
> The real issue is a behavioral inconsistency: every other dblink function that uses the default connection explicitly checks for NULL
> and calls dblink_conn_not_avail() to give a clear error message.
>
> dblink_get_notify() is the only exception, it silently returns an empty result set, which could mislead callers into thinking no
> notifications exist when in fact no connection was established.

dblink_get_notify() was introduced by commit f4095b4c4b2 in 2009,
and it appears to have behaved this way ever since. So there may be
existing systems that depend on the current behavior. Also, there do not
seem to have been any complaints about it over the past 10+ years.

Therefore, unless the current behavior can be shown to cause actual
issues or risks, I'm just feeling tempted to avoid changing it...
At the very least, I don't think we should change the behavior in
the back branches. Thought?

Regards,

-- 
Fujii Masao

Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection

On Fri, Jun 5, 2026 at 10:20 AM Amjad Shahzad
 wrote:
>> I found a NULL pointer dereference in contrib/dblink/dblink.c in the
>> dblink_get_notify() function. Any user with EXECUTE on the function
>> can crash their backend process with a single call. Confirmed against master
>> commit 0392fb900eb.
>>
>> WHAT IS THE ISSUE
>> =================
>> dblink_get_notify() retrieves async notifications from a remote connection.
>> When called with no arguments it uses the default
>> (unnamed) connection. If no default connection has been established first,
>> pconn->conn is NULL. The code assigns this NULL to conn and
>> then passes it directly to PQconsumeInput() and PQnotifies():
>>
>>     /* line 1893 (master) */
>>     else
>>         conn = pconn->conn;      /* NULL — no connection established */
>>
>>     InitMaterializedSRF(fcinfo, 0);
>>
>>     PQconsumeInput(conn);        /* passes NULL to libpq */
>>     while ((notify = PQnotifies(conn)) != NULL)  /* NULL dereference */
>>
>> PQnotifies(NULL) dereferences a null pointer internally, causing a backend
>> SIGSEGV.

Can this segmentation fault actually happen?

PQconsumeInput() and PQnotifies() both simply return immediately when
conn == NULL. So even if dblink_get_notify() calls them with a NULL conn,
it doesn't seem like that would lead to a segmentation fault.
Am I missing something?

Regards,

-- 
Fujii Masao