MIME-Version: 1.0
References: <19511-f9f251767b658232@postgresql.org>
 <CADHzGZRAxFYoxMC+g6pEJ0FL0bfVhFi+y0jQ0cRNCC5hFjvJ3Q@mail.gmail.com>
 <CAHGQGwGt5qAAjgQONmC_sk=O9YtnXxPD12YOy_DODpixPXKU8A@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwGt5qAAjgQONmC_sk=O9YtnXxPD12YOy_DODpixPXKU8A@mail.gmail.com>
From: Amjad Shahzad <amjadshahzad2000@gmail.com>
Date: Fri, 5 Jun 2026 15:55:39 +0500
Message-ID: 
 <CADHzGZSFcQrO4yxa3fua=1=tD9UqU55cNq2es4mt-uVUZKv7cg@mail.gmail.com>
Subject: Re: BUG #19511: contrib/dblink: NULL dereference in
 dblink_get_notify() when called without a prior connection
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000006886c206537f8178"
Archived-At: 
 <https://www.postgresql.org/message-id/CADHzGZSFcQrO4yxa3fua%3D1%3DtD9UqU55cNq2es4mt-uVUZKv7cg%40mail.gmail.com>
Precedence: bulk

--0000000000006886c206537f8178
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Fujii Masao <masao.fujii@gmail.com> =
wrote:

> On Fri, Jun 5, 2026 at 10:20=E2=80=AFAM Amjad Shahzad
> <amjadshahzad2000@gmail.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
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> 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 =3D pconn->conn;      /* NULL =E2=80=94 no connection est=
ablished */
> >>
> >>     InitMaterializedSRF(fcinfo, 0);
> >>
> >>     PQconsumeInput(conn);        /* passes NULL to libpq */
> >>     while ((notify =3D PQnotifies(conn)) !=3D NULL)  /* NULL dereferen=
ce */
> >>
> >> 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 =3D=3D NULL. So even if dblink_get_notify() calls them with a NULL c=
onn,
> it doesn't seem like that would lead to a segmentation fault.
> Am I missing something?
>
> Regards,
>
> --
> Fujii Masao
>

--0000000000006886c206537f8178
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Fujii,<br><br>You are correct. I checked the libpq sour=
ce and both PQconsumeInput() and PQnotifies() have explicit NULL guards:<br=
><br>=C2=A0 =C2=A0 /* fe-exec.c line 2003 */<br>=C2=A0 =C2=A0 if (!conn)<br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;<br><br>=C2=A0 =C2=A0 /* fe-exec.c li=
ne 2688 */<br>=C2=A0 =C2=A0 if (!conn)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 retur=
n NULL;<br><br>So no segmentation fault actually occurs. The function silen=
tly returns 0 rows when called without a prior connection instead of crashi=
ng.<br><br>The real issue is a behavioral inconsistency: every other dblink=
 function that uses the default connection explicitly checks for NULL<br>an=
d calls dblink_conn_not_avail() to give a clear error message.<br><br><div>=
dblink_get_notify() is the only exception, it silently returns an empty res=
ult set, which could mislead callers into thinking no<br>notifications exis=
t when in fact no connection was established. Whether this inconsistency is=
 worth fixing with a proper error message<br>is up to the community&#39;s j=
udgment. I apologize for incorrectly characterizing it as a crash.<br><br>R=
egards,<br>Amjad Shahzad</div></div><br><div class=3D"gmail_quote gmail_quo=
te_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 5, 2026 at =
9:45=E2=80=AFAM Fujii Masao &lt;<a href=3D"mailto:masao.fujii@gmail.com">ma=
sao.fujii@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On Fri, Jun 5, 2026 at 10:20=E2=80=AFAM Amjad Shahzad<br=
>
&lt;<a href=3D"mailto:amjadshahzad2000@gmail.com" target=3D"_blank">amjadsh=
ahzad2000@gmail.com</a>&gt; wrote:<br>
&gt;&gt; I found a NULL pointer dereference in contrib/dblink/dblink.c in t=
he<br>
&gt;&gt; dblink_get_notify() function. Any user with EXECUTE on the functio=
n<br>
&gt;&gt; can crash their backend process with a single call. Confirmed agai=
nst master<br>
&gt;&gt; commit 0392fb900eb.<br>
&gt;&gt;<br>
&gt;&gt; WHAT IS THE ISSUE<br>
&gt;&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt;&gt; dblink_get_notify() retrieves async notifications from a remote co=
nnection.<br>
&gt;&gt; When called with no arguments it uses the default<br>
&gt;&gt; (unnamed) connection. If no default connection has been establishe=
d first,<br>
&gt;&gt; pconn-&gt;conn is NULL. The code assigns this NULL to conn and<br>
&gt;&gt; then passes it directly to PQconsumeInput() and PQnotifies():<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0/* line 1893 (master) */<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0else<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0conn =3D pconn-&gt;conn;=C2=A0 =
=C2=A0 =C2=A0 /* NULL =E2=80=94 no connection established */<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0InitMaterializedSRF(fcinfo, 0);<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0PQconsumeInput(conn);=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 /* passes NULL to libpq */<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0while ((notify =3D PQnotifies(conn)) !=3D NULL)=
=C2=A0 /* NULL dereference */<br>
&gt;&gt;<br>
&gt;&gt; PQnotifies(NULL) dereferences a null pointer internally, causing a=
 backend<br>
&gt;&gt; SIGSEGV.<br>
<br>
Can this segmentation fault actually happen?<br>
<br>
PQconsumeInput() and PQnotifies() both simply return immediately when<br>
conn =3D=3D NULL. So even if dblink_get_notify() calls them with a NULL con=
n,<br>
it doesn&#39;t seem like that would lead to a segmentation fault.<br>
Am I missing something?<br>
<br>
Regards,<br>
<br>
-- <br>
Fujii Masao<br>
</blockquote></div>

--0000000000006886c206537f8178--