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.94.2) (envelope-from ) id 1vBDxq-00D3BT-KV for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Oct 2025 15:07:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vBDxo-00AAwf-AZ for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Oct 2025 15:07:51 +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.94.2) (envelope-from ) id 1vBDwV-00A8Hk-5W for pgsql-bugs@lists.postgresql.org; Tue, 21 Oct 2025 15:06:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vBDwS-003Rw6-0L for pgsql-bugs@lists.postgresql.org; Tue, 21 Oct 2025 15:06:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 59LF6JS6494079; Tue, 21 Oct 2025 11:06:19 -0400 From: Tom Lane To: Daniel Gustafsson cc: 13952878799@163.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech In-reply-to: <64F1394B-E765-4291-91CF-E6CFE019D195@yesql.se> References: <19092-b06adfd70ddcd2ab@postgresql.org> <64F1394B-E765-4291-91CF-E6CFE019D195@yesql.se> Comments: In-reply-to Daniel Gustafsson message dated "Tue, 21 Oct 2025 15:14:08 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <494077.1761059179.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Oct 2025 11:06:19 -0400 Message-ID: <494078.1761059179@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Daniel Gustafsson writes: >> On 21 Oct 2025, at 09:43, PG Bug reporting form wrote: >> The issue is about the only implementation of pg_fe_sasl_mech interface= : >> pg_scram_mech. In the init func of pg_scram_mech, the variable >> state->password is assigned by variable prep_password, which is prepare= d in >> function pg_saslprep(). However, pg_saslprep() will use palloc/pfree or >> malloc/free determined by FRONTEND > Mixing frontend and backend code like that seems to register somewhere o= n the > "break it and you get to keep both pieces" scale. We'd really need to see a concrete example to decide whether this is a PG bug or user error. I think the SASL stuff is sufficiently poorly tested that it could be a previously-unknown PG bug, but it's not clear. So: test case, please. >> This issue occurred when I was attempting to make a connection to Backe= nd >> via libpq interfaces in Backend itself. > You tried to open a new database connection from a backend by embedding = a libpq > client into the backend? postgres_fdw and dblink both do that. The operation is ticklish enough that we've developed some common infrastructure, which maybe you should be using: see src/include/libpq/libpq-be-fe.h and src/include/libpq/libpq-be-fe-helpers.h. regards, tom lane