The rename code can error out prior to the reassignment of the filename,
which is why the test causes a crash.
The rename code can also error out at a later point,
which means it will have already assigned the new filename.
We detect in which case we are in and act accordingly.
Closes GH-19761.
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>
The overflow checking code already existed, but didn't work because the
math was done on signed numbers instead of unsigned numbers.
In the process I also discovered a pre-existing issue that needs to be
fixed (and seems that other stream wrappers can have this issue too).
Closes GH-18644.
PharFileInfo just takes a pointer from the manifest without refcounting
anything. If the entry is then removed from the manifest while the
PharFileInfo object still exists, we get a UAF.
We fix this by using the fp_refcount field. This is technically a
behaviour change as the unlinking is now blocked, and potentially file
modifications can be blocked as well. The alternative would be to have a
field that indicates whether deletion is blocked, but similar corruption
bugs may occur as well with file overwrites, so we increment fp_refcount
instead.
This also fixes an issue where a destructor called multiple times
resulted in a UAF as well, by moving the NULL'ing of the entry field out
of the if.
Closes GH-17811.
Commit edae2431 attempted to fix a leak and double free, but didn't
properly understand what was going on, causing a reference count mistake
and subsequent segfault in this case.
The first mistake of that commit is that the reference count should've
been increased because we're reusing a phar object. The error handling
path should've gotten changed instead to undo this refcount increase
instead of not refcounting at all (root cause of this bug).
The second mistake is that the alias isn't supposed to be transferred or
whatever, that just doesn't make sense. The reason the test
bug69958.phpt originally leaked is because in the non-reuse case we
borrowed the alias and otherwise we own the alias. If we own the alias
the alias information shouldn't get deleted anyway as that would desync
the alias map.
Fixing these will reveal a third issue in which the alias memory is not
always properly in sync with the persistence-ness of the phar, fix this
as well.
Closes GH-17150.
There are two issues:
1) There's an off-by-one in the check for the minimum file size for a
tar (i.e. `>` instead of `>=`).
2) The loop in the tar parsing parses a header, and then unconditionally
reads the next one. However, that doesn't necessarily exist.
Instead, we remove the loop condition and check for the end of the
file before reading the next header. Note that we can't use
php_stream_eof as the flag may not be set yet when we're already at
the end.
Closes GH-16700.
Niels Dossche