From 1f49beef271ef920f129fcb8513c56347803444a Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Mon, 10 Aug 2026 06:38:36 -0700 Subject: [PATCH] Cross-check the type of a portal running EXECUTE or FETCH. When an EXECUTE or FETCH statement is executed, there are two portals: an outer portal that is created for the EXECUTE or FETCH statement itself, and an inner portal for the statement being executed on its behalf. Before this commit, nothing checked that these two portals agreed on the tuple descriptor of the rows being returned. This can be leveraged to disclose server memory contents and achieve arbitrary code execution. To prevent that, we can make use of an existing safety mechanism, added by Tom Lane in commit 2f48ede080f42b97b594fb14102c82ca1001b80c, which allows a tuplestore DestReceiver to be informed of the tupleDesc required by the caller, and which will cause an ERROR to occur if that doesn't match the tupleDesc of what emerges from the executor (modulo dropped columns, which aren't an issue in the case at hand). Reported-by: Ben Morris in collaboration with Claude and Anthropic Research Reported-by: Peter Geoghegan Reviewed-by: Michael Paquier Security: CVE-2026-16239 --- src/backend/tcop/pquery.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c index 33eb563044d..4b8833f5d30 100644 --- a/src/backend/tcop/pquery.c +++ b/src/backend/tcop/pquery.c @@ -1004,8 +1004,8 @@ FillPortalStore(Portal portal, bool isTopLevel) portal->holdStore, portal->holdContext, false, - NULL, - NULL); + portal->tupDesc, + gettext_noop("query result type does not match portal result type")); switch (portal->strategy) {