ext/pgsql: Fix #19484 by setting the notice processor to a no-op #19485
Conversation
…stent connection is cleaned for future use
MagicalTux
changed the title
ext/pgsql/pgsql.c
Outdated
|
|
||
| link = (PGconn *) rsrc->ptr; | ||
|
|
||
| /* unset notice processor */ |
There was a problem hiding this comment.
nit:
if (!PGG(ignore_notices)) {
PQsetNoticeProcessor(link, _php_pgsql_notice_handler, NULL);
}wdyt ?
There was a problem hiding this comment.
or possibly fetching the actual handler -> checking that is _php_pgsql_notice_handler -> unsetting it if yes
There was a problem hiding this comment.
If ignore_notices (pgsql.ignore_notice without a s) is changed at runtime there is a risk we could have set the callback but fail to unset it. To be quite honest I am not sure if that's a risk at all, however setting it to a no-op should be safe either way.
The best way would be of course to check if we did set the callback by either storing a flag somewhere, or as an alternative check if the current callback is ours with:
if (PQsetNoticeProcessor(link, NULL, NULL) == _php_pgsql_notice_handler) {
PQsetNoticeProcessor(link, _php_pgsql_notice_handler, NULL);
}There was a problem hiding this comment.
yes
or possibly fetching the actual handler -> checking that is _php_pgsql_notice_handler -> unsetting it if yes
|
Nice ! If you want, please credit yourself in NEWS by creating a PGSQL section for PHP 8.3.26 with |
2 participants
Resolving a potential use after free of the pgsql connection object.
See #19484 for details.