From c2569aaa56cbaba40f83680fafd71ca9ad11331a Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Mon, 11 Nov 2024 10:20:01 +0900 Subject: [PATCH 1/3] libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 --- doc/src/sgml/protocol.sgml | 21 +++++++++++---------- src/interfaces/libpq/fe-connect.c | 15 ++++++--------- 2 files changed, 17 insertions(+), 19 deletions(-) diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index cf1fadcda4b..9072cf847e4 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1526,10 +1526,10 @@ SELCT 1/0; The frontend should also be prepared to handle an ErrorMessage - response to SSLRequest from the server. This would only occur if - the server predates the addition of SSL support - to PostgreSQL. (Such servers are now very ancient, - and likely do not exist in the wild anymore.) + response to SSLRequest from the server. The frontend should not display + this error message to the user/application, since the server has not been + authenticated + (CVE-2024-10977). In this case the connection must be closed, but the frontend might choose to open a fresh connection and proceed without requesting SSL. @@ -1603,12 +1603,13 @@ SELCT 1/0; The frontend should also be prepared to handle an ErrorMessage - response to GSSENCRequest from the server. This would only occur if - the server predates the addition of GSSAPI encryption - support to PostgreSQL. In this case the - connection must be closed, but the frontend might choose to open a fresh - connection and proceed without requesting GSSAPI - encryption. + response to GSSENCRequest from the server. The frontend should not display + this error message to the user/application, since the server has not been + authenticated + (CVE-2024-10977). + In this case the connection must be closed, but the frontend might choose + to open a fresh connection and proceed without requesting + GSSAPI encryption. diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index 7f3dfd462a6..be288ff8bd5 100644 --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -3168,16 +3168,13 @@ PQconnectPoll(PGconn *conn) { /* * Server failure of some sort, such as failure to - * fork a backend process. We need to process and - * report the error message, which might be formatted - * according to either protocol 2 or protocol 3. - * Rather than duplicate the code for that, we flip - * into AWAITING_RESPONSE state and let the code there - * deal with it. Note we have *not* consumed the "E" - * byte here. + * fork a backend process. Don't bother retrieving + * the error message; we should not trust it as the + * server has not been authenticated yet. */ - conn->status = CONNECTION_AWAITING_RESPONSE; - goto keep_going; + appendPQExpBuffer(&conn->errorMessage, + libpq_gettext("server sent an error response during SSL exchange\n")); + goto error_return; } else { From 174691bee28d51e656e79cb101bfb202909e3e68 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Mon, 5 Feb 2024 11:01:30 +0200 Subject: [PATCH 2/3] Fix assertion if index is dropped during REFRESH CONCURRENTLY When assertions are disabled, the built SQL statement is invalid and you get a "syntax error". So this isn't a serious problem, but let's avoid the assertion failure. Backpatch to all supported versions. Reviewed-by: Noah Misch --- src/backend/commands/matview.c | 7 +++++-- src/test/regress/expected/matview.out | 16 ++++++++++++++++ src/test/regress/sql/matview.sql | 17 +++++++++++++++++ 3 files changed, 38 insertions(+), 2 deletions(-) diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c index 1555ea9d334..b5619240c9e 100644 --- a/src/backend/commands/matview.c +++ b/src/backend/commands/matview.c @@ -1347,9 +1347,12 @@ refresh_by_match_merge(Oid matviewOid, Oid tempOid, Oid relowner, * * ExecRefreshMatView() checks that after taking the exclusive lock on the * matview. So at least one unique index is guaranteed to exist here - * because the lock is still being held; so an Assert seems sufficient. + * because the lock is still being held. (One known exception is if a + * function called as part of refreshing the matview drops the index. + * That's a pretty silly thing to do.) */ - Assert(foundUniqueIndex); + if (!foundUniqueIndex) + elog(ERROR, "could not find suitable unique index on materialized view"); diff --git a/src/test/regress/expected/matview.out b/src/test/regress/expected/matview.out index 1f33fdbc1f7..db5c4ea6ac8 100644 --- a/src/test/regress/expected/matview.out +++ b/src/test/regress/expected/matview.out @@ -619,6 +619,22 @@ REFRESH MATERIALIZED VIEW mvtest_mv_foo; REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_mv_foo; DROP OWNED BY regress_user_mvtest CASCADE; DROP ROLE regress_user_mvtest; +-- Concurrent refresh requires a unique index on the materialized +-- view. Test what happens if it's dropped during the refresh. +CREATE OR REPLACE FUNCTION mvtest_drop_the_index() + RETURNS bool AS $$ +BEGIN + EXECUTE 'DROP INDEX IF EXISTS mvtest_drop_idx'; + RETURN true; +END; +$$ LANGUAGE plpgsql; +CREATE MATERIALIZED VIEW drop_idx_matview AS + SELECT 1 as i WHERE mvtest_drop_the_index(); +NOTICE: index "mvtest_drop_idx" does not exist, skipping +CREATE UNIQUE INDEX mvtest_drop_idx ON drop_idx_matview (i); +REFRESH MATERIALIZED VIEW CONCURRENTLY drop_idx_matview; +ERROR: could not find suitable unique index on materialized view +DROP MATERIALIZED VIEW drop_idx_matview; -- clean up -- make sure that create WITH NO DATA works via SPI BEGIN; CREATE FUNCTION mvtest_func() diff --git a/src/test/regress/sql/matview.sql b/src/test/regress/sql/matview.sql index 9b4e0d7d0e9..1b26b26ab38 100644 --- a/src/test/regress/sql/matview.sql +++ b/src/test/regress/sql/matview.sql @@ -236,6 +236,23 @@ REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_mv_foo; DROP OWNED BY regress_user_mvtest CASCADE; DROP ROLE regress_user_mvtest; +-- Concurrent refresh requires a unique index on the materialized +-- view. Test what happens if it's dropped during the refresh. +CREATE OR REPLACE FUNCTION mvtest_drop_the_index() + RETURNS bool AS $$ +BEGIN + EXECUTE 'DROP INDEX IF EXISTS mvtest_drop_idx'; + RETURN true; +END; +$$ LANGUAGE plpgsql; + +CREATE MATERIALIZED VIEW drop_idx_matview AS + SELECT 1 as i WHERE mvtest_drop_the_index(); + +CREATE UNIQUE INDEX mvtest_drop_idx ON drop_idx_matview (i); +REFRESH MATERIALIZED VIEW CONCURRENTLY drop_idx_matview; +DROP MATERIALIZED VIEW drop_idx_matview; -- clean up + -- make sure that create WITH NO DATA works via SPI BEGIN; CREATE FUNCTION mvtest_func() From f893f35b90caf1d4acf4ca21f2d658f1009efb89 Mon Sep 17 00:00:00 2001 From: reshke Date: Mon, 23 Mar 2026 09:32:54 +0000 Subject: [PATCH 3/3] Add allow_segment_DML to utility test function --- src/test/regress/sql/matview.sql | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/test/regress/sql/matview.sql b/src/test/regress/sql/matview.sql index 1b26b26ab38..b24d4272a74 100644 --- a/src/test/regress/sql/matview.sql +++ b/src/test/regress/sql/matview.sql @@ -238,6 +238,7 @@ DROP ROLE regress_user_mvtest; -- Concurrent refresh requires a unique index on the materialized -- view. Test what happens if it's dropped during the refresh. +SET allow_segment_DML = ON; CREATE OR REPLACE FUNCTION mvtest_drop_the_index() RETURNS bool AS $$ BEGIN @@ -245,6 +246,7 @@ BEGIN RETURN true; END; $$ LANGUAGE plpgsql; +RESET allow_segment_DML; CREATE MATERIALIZED VIEW drop_idx_matview AS SELECT 1 as i WHERE mvtest_drop_the_index();