[PATCH] pgcrypto: Ensure debug handler is reset on error in PGP functions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253464psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:29 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253464_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253464_1 && git checkout t253464_1Patchset v1 (message #1) is on t253464_1
Hi, while backporting CVE-2026-14663 to WarehousePG, I found a debug
handler leak issue.
The PGP encryption and decryption functions install a global debug
handler when the "debug=1" option is given, and relied on every error
path explicitly resetting it before throwing. Commit d0ecee6de9a
added an ereport() call in cfb_process() which can fire while the
handler is installed, for example when a cipher fails its deferred
initialization under OpenSSL running in FIPS mode or without the
legacy provider loaded. The error would leave the handler installed
for the remainder of the backend's lifetime, causing subsequent PGP
calls in the same backend to emit "dbg:" NOTICE messages even without
the debug option, until some PGP call happened to complete normally.
CREATE EXTENSION pgcrypto;
-- 1) Trigger: debug=1 installs the global debug handler; blowfish passes
-- pgp_cfb_create() but fails its deferred EVP initialization inside
-- cfb_process(), whose ereport() longjmps past the handler reset.
-- (Requires OpenSSL 3 without the legacy provider, or FIPS mode.)
SELECT pgp_sym_encrypt('x', 'k', 'debug=1, cipher-algo=bf');
-- ERROR: encrypt error: Cipher cannot be initialized
-- 2) The leak becomes visible
SELECT pgp_sym_decrypt('\x00'::bytea, 'k');
-- NOTICE: dbg: pgp_parse_pkt_hdr: not pkt hdr <- leaked handler
-- ERROR: Wrong key or corrupt data
Rather than adding yet another explicit reset at the new error site,
wrap the bodies of encrypt_internal() and decrypt_internal() in
PG_TRY/PG_FINALLY so that the handler is reset no matter how we exit.
This also closes preexisting windows of the same kind, such as an
encoding conversion error or out-of-memory failure occurring while
the handler is installed, and lets us remove the reset calls that
were previously scattered across the success and error paths.
No memory or resource cleanup needs to be moved into the PG_FINALLY
block: all allocations are palloc-based and OpenSSL handles are
tracked by ResourceOwner, so error recovery already takes care of
those.
On 18 Aug 2026, at 12:42, Keyerror Smart <smartkeyerror@gmail.com> wrote:
Hi, while backporting CVE-2026-14663 to WarehousePG, I found a debug
handler leak issue.
This was actually discussed during the development for the security fix, but
fixing it was deemed out of scope to keep the security fix as minimal and
focused as possible. The plan was to revisit once shipped, but no one has had
time to do that yet so thanks for tackling it.
I have your patch on my radar but there is currently a lot going on with
preparing 19 so bear with me as we work our way down the list.
--
Daniel Gustafsson
I have your patch on my radar but there is currently a lot going on with
preparing 19 so bear with me as we work our way down the list.
Thanks for the update and context! No rush at all, take your time with the
19 release preparation.
Daniel Gustafsson <daniel@yesql.se> 于2026年8月27日周四 05:57写道:
Show quoted text
On 18 Aug 2026, at 12:42, Keyerror Smart <smartkeyerror@gmail.com>
wrote:
Hi, while backporting CVE-2026-14663 to WarehousePG, I found a debug
handler leak issue.This was actually discussed during the development for the security fix,
but
fixing it was deemed out of scope to keep the security fix as minimal and
focused as possible. The plan was to revisit once shipped, but no one has
had
time to do that yet so thanks for tackling it.I have your patch on my radar but there is currently a lot going on with
preparing 19 so bear with me as we work our way down the list.--
Daniel Gustafsson