This would allocate a too small buffer if the first smart_str
allocation is > SMART_STR_START_LEN but <= SMART_STR_START_SIZE.
(cherry picked from commit af8fccee9c)
A recent bug fix regarding symlinks claimed:
> After resolving reparse points, the path still may be a reparse
> point; in that case we have to resolve that reparse point as well.
While that is basically correct, some reparse points may point to
inaccessible system folders (e.g. `IO_REPARSE_TAG_DEDUP` points to
"\System Volume Information"). Since we don't know details about
arbitrary reparse points, and are mainly interested in nested symlinks,
we take a step back, and only resolve `IO_REPARSE_TAG_SYMLINK` for now.
Close GH-6354.
If the RHS has INDIRECT elements, we do not those to be added to
the LHS verbatim. As we're using UPDATE_INDIRECT, we might even
create a nested INDIRECT that way.
This is a side-quest of oss-fuzz #26245.
Do not decrement the refcount before allocating the new string,
as the allocation operation may bail out and cause a use-after-free
lateron. We can only decrement the refcount once the allocation
has succeeded.
Fixes oss-fuzz #25384.
Use the general zend_generator_throw_exception() helper for this.
Otherwise we don't handle the off-by-one opline correctly (should
we maybe just stop doing that?)
This is a followup to ad750c3bb6,
which fixed a different yield from exception handling problem that
happened to show up in the same test case from oss-fuzz #25321.
Now both issues should be fixed.
There is a deeper underlying issue here, in that the opcodes violate
VM write-fetch safety, but let's fix the infinite loop first.
This fixes oss-fuzz #25352.
In the interest of avoiding side-effects during dumping, I'm
replacing the value with a <constant ast> string instead of
performing an update constant operation.
Fixes a use-after-free encountered in Symfony's SecurityBundle.
I don't have a reproducer for this, and believe the issue can only
occur if we leak an iterator (the leak is a separate issue).
We should not free the generator iterator here, because we do not
own it. The code that fetched the iterator is responsible for
releasing it. In the rare case where we do hit this code-path,
we cause a use-after-free.
