From 067a64d40f92e4e012db0367f9ff2d2ae45671ca Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Mon, 10 Aug 2026 06:38:18 -0700 Subject: [PATCH] Reject GSSEncRequest after direct SSL connection When a direct SSL connection was established, ProcessStartupPacket() still accepted GSSEncRequest messages. The GSSAPI negotiation would then use raw writes and reads, bypassing the TLS encryption layer. After the GSS encryption was established, the connection continued to use TLS. This could betray the HBA rules so as the backend does protocol exchanges inconsistent with the connection policies in place, with TLS taking priority over GSS in the backend. The SSL negotiation path already guarded against attempts to request SSL after a direct SSL request has been processed. The GSS path is now guarded the same way when receiving a startup packet. Reported-by: p4p3r Author: Michael Paquier Reviewed-by: Jacob Champion Backpatch-through: 17 Security: CVE-2026-14681 --- src/backend/tcop/backend_startup.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c index 2fe67015e3b..4dd4d35e6b4 100644 --- a/src/backend/tcop/backend_startup.c +++ b/src/backend/tcop/backend_startup.c @@ -625,8 +625,13 @@ retry: char GSSok = 'N'; #ifdef ENABLE_GSS - /* No GSSAPI encryption when on Unix socket */ - if (port->laddr.addr.ss_family != AF_UNIX) + + /* + * No GSSAPI encryption when on Unix socket. + * + * Also no GSS negotiation if we already have a direct SSL connection. + */ + if (port->laddr.addr.ss_family != AF_UNIX && !port->ssl_in_use) GSSok = 'G'; #endif