pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
5+ messages / 5 participants
[nested] [flat]
* BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
@ 2025-10-21 07:43 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: PG Bug reporting form @ 2025-10-21 07:43 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: 13952878799@163.com
The following bug has been logged on the website:
Bug reference: 19092
Logged by: NJUEEXRM
Email address: 13952878799@163.com
PostgreSQL version: 17.0
Operating system: MacOS 12.7.6
Description:
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 prepared in
function pg_saslprep(). However, pg_saslprep() will use palloc/pfree or
malloc/free determined by FRONTEND marco。If we are in backend env，the
prep_password will be palloc-ed in CurrentMemoryContext. The problem is
state->password will be released by free() in the free func of
pg_scram_mech: scram_free, and will cause 'free on address which was not
malloc()-ed' error.
This issue occurred when I was attempting to make a connection to Backend
via libpq interfaces in Backend itself.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
@ 2025-10-21 13:14 Daniel Gustafsson <daniel@yesql.se>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2025-10-21 13:14 UTC (permalink / raw)
To: 13952878799@163.com; pgsql-bugs@lists.postgresql.org
> On 21 Oct 2025, at 09:43, PG Bug reporting form <noreply@postgresql.org> 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 prepared in
> function pg_saslprep(). However, pg_saslprep() will use palloc/pfree or
> malloc/free determined by FRONTEND marco。If we are in backend env，the
> prep_password will be palloc-ed in CurrentMemoryContext. The problem is
> state->password will be released by free() in the free func of
> pg_scram_mech: scram_free, and will cause 'free on address which was not
> malloc()-ed' error.
Mixing frontend and backend code like that seems to register somewhere on the
"break it and you get to keep both pieces" scale.
> This issue occurred when I was attempting to make a connection to Backend
> 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? Which problem are you trying to solve, maybe there is
an easier way?
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
@ 2025-10-21 15:06 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2025-10-21 15:06 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: 13952878799@163.com; pgsql-bugs@lists.postgresql.org
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 21 Oct 2025, at 09:43, PG Bug reporting form <noreply@postgresql.org> 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 prepared 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 on 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 Backend
>> 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
@ 2025-10-23 00:29 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Michael Paquier @ 2025-10-23 00:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Daniel Gustafsson <daniel@yesql.se>; 13952878799@163.com; pgsql-bugs@lists.postgresql.org
On Tue, Oct 21, 2025 at 11:06:19AM -0400, Tom Lane wrote:
> 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.
[ .. double-checking the code .. ]
FWIW, I doubt that this is something we need to worry about and I
suspect that there is no action item here. dblink and WAL receivers
do their stuff so as the main backend code does not link with libpq,
and I doubt that we'd ever want to enter in the territory where
FRONTEND becomes a thing in libpq.
Of course, I may prove wrong.
> So: test case, please.
Yes.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../aPl235F3k3ZDeAfj@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
@ 2025-10-23 15:05 Jacob Champion <jacob.champion@enterprisedb.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 5+ messages in thread
From: Jacob Champion @ 2025-10-23 15:05 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Daniel Gustafsson <daniel@yesql.se>; 13952878799@163.com; pgsql-bugs@lists.postgresql.org
On Wed, Oct 22, 2025 at 5:29 PM Michael Paquier <michael@paquier.xyz> wrote:
> > So: test case, please.
>
> Yes.
Thirded.
The only thing I can think of at the moment -- which a test case would
quickly prove or disprove -- is that the symbol visibility is messed
up for this particular build in some way, and libpq's pg_saslprep has
been incorrectly preempted by postgres' pg_saslprep. But I can't
reproduce anything like that with my local macOS build.
--Jacob
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-10-23 15:05 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-21 07:43 BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech PG Bug reporting form <noreply@postgresql.org>
2025-10-21 13:14 ` Daniel Gustafsson <daniel@yesql.se>
2025-10-21 15:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-10-23 00:29 ` Michael Paquier <michael@paquier.xyz>
2025-10-23 15:05 ` Jacob Champion <jacob.champion@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox