BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
В списке pgsql-bugs по дате отправления:
| От | PG Bug reporting form |
|---|---|
| Тема | BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech |
| Дата | |
| Msg-id | 19092-b06adfd70ddcd2ab@postgresql.org обсуждение исходный текст |
| Ответы |
Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech
|
| Список | pgsql-bugs |
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.
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера