The `defaultMemoryManager` is only available via a non-public
header and is not supposed to be used by users of the library [1].
It also has a very generic name, further indicating that it is not
supposed to be used.
Instead pass the memory manager explicitly, which is how the library is
supposed to be used.
[1] https://github.com/uriparser/uriparser/issues/52#issuecomment-453853700
There are two bugfixes here.
The first was a crash that I discovered while working on GH-19035.
The check for when a file pointer was still occupied was wrong, leading
to a UAF. Strangely, zip got this right.
The second issue was that even after fixing the first one, the file
contents were garbage. This is because the file write offset for the
phar stream was wrong.
Closes GH-19038.
The copy function does two things wrong:
- The error recovery logic is a hack that temporarily moves the fp
pointer to cfp, even though it's not compressed. The respective error
recovery it talks about is not present in the code, nor is it
necessary. This is the direct cause of the double free in the original
reproducer. Fixing this makes it crash in another location though.
- The link following logic is inconsistent and illogical. It cannot be a
link at this point.
The root cause, after fixing the above issues, is that the file pointers
are not reset properly for the copy. The file pointer need to be the
original ones to perform the copy from the right source, but after that
they need to be set properly to NULL (because fp_type == PHAR_FP).
Closes GH-19035.
Co-authored-by: Yun Dou <dixyes@gmail.com>
Both these issues have the same root cause, their reproducer is
extremely similar so I don't duplicate the test.
If the parser invokes the lexer, and the lexer fails, it could've
allocated a string which must be freed when the parser backs up.
The `%destructor` list is responsible for this but did not have an entry
for `fallback` yet. Solve the issue by adding such an entry.
Closes GH-19012.
The code is already looking up the entry in the function table anyway,
so might as well use it directly.
This simplifies the code and avoids a redundant lookup.
Apple Silicon has stricter rules about rwx mmap regions. They need to be created
using the MAP_JIT flag. However, the MAP_JIT seems to be incompatible with
MAP_SHARED. ZTS requires MAP_SHARED so that some threads may execute code from a
page while another writes/appends to it. We did not find another solution, other
than completely disabling JIT for Apple Silicon + ZTS.
See discussion in https://github.com/php/php-src/pull/13351.
Co-authored-by: Peter Kokot <peterkokot@gmail.com>
Fixes GH-13400
Closes GH-13396
