On Fri, Jun 5, 2026 at 10:20 AM 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
>> =================
>> 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
