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

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. Whether
this inconsistency is worth fixing with a proper error message
is up to the community's judgment. I apologize for incorrectly
characterizing it as a crash.

Regards,
Amjad Shahzad

On Fri, Jun 5, 2026 at 9:45 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Fri, Jun 5, 2026 at 10:20 AM Amjad Shahzad
> <amjadshahzad2000(at)gmail(dot)com> 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
>