| From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | 13952878799(at)163(dot)com |
| Subject: | BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech |
| Date: | 2025-10-21 07:43:58 |
| Message-ID: | 19092-b06adfd70ddcd2ab@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 19092
Logged by: NJUEEXRM
Email address: 13952878799(at)163(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Miroslav Pankov | 2025-10-21 08:15:29 | TLS verification to intermediate trust anchor with psql |
| Previous Message | David Rowley | 2025-10-21 07:05:09 | Re: postgres access violation in pg_detoast_datum |