Open cla7aye15I4nd opened 2 weeks ago
cc @nielsdos @iluuu1994
I can confirm the UAF, but this is not a vulnerability (just really nonsenstical PHP code).
Right. There are so many of them I'm honestly not sure they are worth investing more time in... set_error_handler()
is inherently problematic and these fixes are just making the code more complex, less readable, and often less performant. We have a few options, namely to delay error handlers (attempted in GH-12805), to phase out error handlers in favor of more targeted hooks (e.g. for logging, promoting to exceptions, etc.) without full user callbacks, or to just ignore the issue altogether.
Unfortunately, the same issue often goes for __toString()
, which is likely even harder to solve.
I don't know why you think this was fixed by https://github.com/php/php-src/commit/24ff7eee3f04070d8ab1b31f57d17f0c840185bf, but it's not. It's unrelated.
Yes. I believe the bug never be repaired, I am curious why it is marked as fixed in OSS repo at here https://github.com/google/oss-fuzz-vulns/blob/main/vulns/php/OSV-2021-1199.yaml#L27
Description
Description: I encountered a heap UAF bug in PHP with commit fb257ee83c405fecf449571bfcd1cc0fb4910336 I built the binary following OSS-Fuzz's guidelines, and the bug was reproduced in
php-fuzz-execute
.This test case is a regression of OSV-2021-1199 (details here), which was marked as fixed in commit 24ff7eee3f04070d8ab1b31f57d17f0c840185bf.
Sanitizer Report: The sanitizer report is as follows:
Please investigate and provide feedback. This issue might represent a reoccurrence of a previously patched vulnerability.
PHP Version
fb257ee83c405fecf449571bfcd1cc0fb4910336
Operating System
No response