Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection
От
Fujii Masao
Тема
Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection
Дата
Msg-id
CAHGQGwGt5qAAjgQONmC_sk=O9YtnXxPD12YOy_DODpixPXKU8A@mail.gmail.com
Список
Дерево обсуждения
Re: [PATCH v1 0/3] Route crypto through the OpenSSL 3 provider API Michael Paquier <michael@paquier.xyz>
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
В списке pgsql-bugs по дате отправления
От: Ayush Tiwari
Дата:
От: Alexander Lakhin
Дата: