Hi internals
Based on https://bugs.php.net/bug.php?id=71571 I've opened a PR to implement two new properties for XSLTProcessor: maxTemplateDepth and maxTemplateVars. The reasoning behind this is that large templates with lots of recursion and/or variables can bump against the default recursion limit set by the libxslt library.
PR link: https://github.com/php/php-src/pull/13731
I used an adapted version of https://github.com/nikic/popular-package-analysis to download every package that satisfies the search term "xsl". Then I checked if there are any classes that extend XSLTProcessor and have the maxTemplateDepth or maxTemplateVars field.
None do, and as such no package in packagist will observe a BC break because of this PR.
One sad detail however, is that you can set the recursion limit so high that you can exhaust the stack space, which will crash the process with a segfault. In fact, you can hit this already right now without the PR, using XSL. I.e. you can create a very deep VM re-entry that won't cause the stack limit protection to kick in, and then start a recursive XSL template processing that does not hit XSL's limit, but exhausts the remaining stack space. Note that as soon as you do callbacks however, the stack limit protection will kick in.
I tried to check if it's possible to prevent this, but the stack limit check would need to happen inside the libxslt library, so I don't think it's possible.
Let me know if there are any complaints about this. If no complaints, I'll merge this in 2 weeks or so.
Kind regards
Niels
Hi Niels,
On Sat, Mar 16, 2024 at 5:49 PM Niels Dossche dossche.niels@gmail.com
wrote:
Hi internals
Based on https://bugs.php.net/bug.php?id=71571 I've opened a PR to
implement two new properties for XSLTProcessor: maxTemplateDepth and
maxTemplateVars. The reasoning behind this is that large templates with
lots of recursion and/or variables can bump against the default recursion
limit set by the libxslt library.PR link: https://github.com/php/php-src/pull/13731
I used an adapted version of
https://github.com/nikic/popular-package-analysis to download every
package that satisfies the search term "xsl". Then I checked if there are
any classes that extend XSLTProcessor and have the maxTemplateDepth or
maxTemplateVars field.
None do, and as such no package in packagist will observe a BC break
because of this PR.One sad detail however, is that you can set the recursion limit so high
that you can exhaust the stack space, which will crash the process with a
segfault. In fact, you can hit this already right now without the PR, using
XSL. I.e. you can create a very deep VM re-entry that won't cause the stack
limit protection to kick in, and then start a recursive XSL template
processing that does not hit XSL's limit, but exhausts the remaining stack
space. Note that as soon as you do callbacks however, the stack limit
protection will kick in.
I tried to check if it's possible to prevent this, but the stack limit
check would need to happen inside the libxslt library, so I don't think
it's possible.Let me know if there are any complaints about this. If no complaints, I'll
merge this in 2 weeks or so.Kind regards
Niels
For PCRE there is a pcre.recursion_limit setting [1] with the same issue.
This is fine because that's a convenience feature (not a security one) and
it is useful by catching most cases of uncontrolled recursion in practice.
The default value is not changed by this PR (so there is no risk of BC
break by lowering the limit), and appears to be low enough to prevent stack
exhaustions on a default 2MiB stack on Linux.
+1 for this
[1]
https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit
Kind regards,
Arnaud