-
Notifications
You must be signed in to change notification settings - Fork 7.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
php-fpm: zend_mm_heap corrupted with cgi-fcgi request #15395
Comments
oldest version i could test was 7.1.33 and the bug is present there as well. |
So it seems, it is the auth password part which triggers the fault, with ASAN we can see it crashes on request shutdown, root cause seems to be the auth data handling. |
But we still consider the authentication handling Basic part successful.
just to be clear, this example is just with an user, because that was enough. |
I cannot reproduce with a password, do you have an example where it crashes still ? |
so within our k8s setup it definitley crashed with a password provided. using
but still dump out a weird user into the log 🤔 notice the |
here is an example which triggered the heap corruption:
|
I could reproduce the dangling display in my side. I use your example, only I build my own php inside the container. |
But we still consider the authentication handling Basic part successful.
But we still consider the authentication handling Basic part successful.
Co-authored-by: David Carlier <devnexen@gmail.com> Closes phpGH-16227
Description
after making a request with a
HTTP_AUTHORIZATION
header, a subsequentcgi-fcgi -bind -connect 127.0.0.1:9000
will fail and cause heap corruption + SIGABRT on the child process.poc:
with that, the setup is complete and you can now trigger the bug with this running in the container:
you might need to retry to hit the correct child which served the previous request.
this seems to affect at least all php 8 versions starting with 8.0.0
i did not check older version though.
we use the connect to the port 9000 as a liveness probe for kubernetes like this:
and we noticed a service with that setup failing due to the command returning a non-zero exit code and the thus the pod being restarted while the service receives requests with HTTP_AUTH headers.
the bug can not be triggered without the
HTTP_AUTHORIZATION
request. and it looks like memory contents might get dumped into the log too 🤔PHP Version
PHP 8.3.10
Operating System
debian
The text was updated successfully, but these errors were encountered: