Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wbgi0-002lY8-1v for pgsql-bugs@arkaria.postgresql.org; Mon, 22 Jun 2026 15:37:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wbghz-007MGH-1G for pgsql-bugs@arkaria.postgresql.org; Mon, 22 Jun 2026 15:37:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1waHJc-00D6NW-2k for pgsql-bugs@lists.postgresql.org; Thu, 18 Jun 2026 18:18:12 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1waHJY-000000018e9-2j59 for pgsql-bugs@lists.postgresql.org; Thu, 18 Jun 2026 18:18:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=4dN6ChsBnVQ0/f5laWiJIUgBmmeQGexDEtB0VSj7SB8=; b=wN6pS55spoOvj+5mxevByYjWgT lIQjmzwkWTws9VidduWsQPOcjY3z6ZEvValS3dTtskH2yj84uXLbIn35ZJ2MkeB8gYcKXbd/Vy+tK tY9GCdC7LMpbz3xRSg5IFfl3D8F5Z+niTysT8grJj6KQgLdF1xwHS8AJ0B2qrdS7wetNarr+tt5JT hUyFhaSeKgH6SGj9vPlGeDteN7niO3bK8JzeDTyPQV4j2O8AhNVuHa8ITD1B6lospUorLTSfpw4H6 pghGZF1FEsCgjTt1HDb9pGX/VdNpqfdgXVZp+Hh258gXTGOOJ+ZqHFgviC7yWGeL6SvTSHjlhH3Q+ gmeik2kw==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1waHJU-00346m-2I for pgsql-bugs@lists.postgresql.org; Thu, 18 Jun 2026 18:18:06 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1waHJT-006uje-0R for pgsql-bugs@lists.postgresql.org; Thu, 18 Jun 2026 18:18:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19527: Double-Abort Crash in `ResOwnerReleaseOSSLCipher` via `encrypt_iv` with Oversized Input To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: 3020001251@tju.edu.cn Reply-To: 3020001251@tju.edu.cn, pgsql-bugs@lists.postgresql.org Date: Thu, 18 Jun 2026 18:17:12 +0000 Message-ID: <19527-6e7686960c6dce78@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19527 Logged by: Yuelin Wang Email address: 3020001251@tju.edu.cn PostgreSQL version: 19beta1 Operating system: Linux (Ubuntu 24.04, x86_64) Description: =20 **Component**: `contrib/pgcrypto/openssl.c`, `ResOwnerReleaseOSSLCipher` (line 833), `free_openssl_cipher` (line 291) Any role with `EXECUTE` on `encrypt_iv` (granted by default when pgcrypto is installed) can crash the backend with a single statement: ```sql CREATE EXTENSION IF NOT EXISTS pgcrypto; SELECT encrypt_iv( repeat('A', 1073741308)::bytea, decode('00112233445566778899aabbccddeeff', 'hex'), decode('000102030405060708090a0b0c0d0e0f', 'hex'), 'aes' ); ``` Expected vs actual output: | Step | Expected | Actual | |---|---|---| | `encrypt_iv(...)` | `ERROR: invalid memory alloc request size ...` then clean abort | `WARNING: AbortTransaction while in ABORT state` followed by `ERROR: ResourceOwnerForget called for pgcrypto OpenSSL cipher handle after release started` then backend crash | | Server state after | Normal | `FATAL: the database system is in recovery mode` (postmaster restarted) | `1073741308 + 512 + 4 =3D 1073741824 =3D 0x40000000 > MaxAllocSize (0x3FFFFFFF)`, so `palloc` throws `ERROR` and longjmps past `px_combo_free`, leaving the `OSSLCipher` registered with the current `ResourceOwner`. When `AbortTransaction` calls `ResourceOwnerRelease`, `ResOwnerReleaseOSSLCipher` calls `free_openssl_cipher` with `od->owner` still set. `free_openssl_cipher` then calls `ResourceOwnerForgetOSSLCipher`, which checks `owner->releasing =3D=3D true` and throws `elog(ERROR, ...)`. An ERR= OR thrown inside `AbortTransaction` re-enters `AbortCurrentTransaction`, calling `ResourceOwnerRelease` a second time on the already-released owner. The second call invokes `EVP_CIPHER_CTX_free` on the already-freed EVP context, producing a null pointer dereference (ASan: `SEGV in EVP_CIPHER_CTX_reset`). Server output: ``` WARNING: AbortTransaction while in ABORT state ERROR: ResourceOwnerForget called for pgcrypto OpenSSL cipher handle after release started server closed the connection unexpectedly ``` ASan confirmation: ``` =3D=3DERROR: AddressSanitizer: SEGV on unknown address 0x000000000659 #0 EVP_CIPHER_CTX_reset (libcrypto.so.3) #1 EVP_CIPHER_CTX_free (libcrypto.so.3) #2 free_openssl_cipher openssl.c:294 #3 ResOwnerReleaseOSSLCipher openssl.c:835 #4 ResourceOwnerReleaseAll resowner.c:395 #5 AbortTransaction xact.c:3016 SUMMARY: AddressSanitizer: SEGV (EVP_CIPHER_CTX_reset) ``` The fix is to clear `od->owner` before calling `free_openssl_cipher` in `ResOwnerReleaseOSSLCipher`: ```c static void ResOwnerReleaseOSSLCipher(Datum res) { OSSLCipher *od =3D (OSSLCipher *) DatumGetPointer(res); od->owner =3D NULL; free_openssl_cipher(od); } ```