XSLTProcessor recursion limit
| From: | Niels Dossche | Date: | Sat, 16 Mar 2024 16:48:50 +0000 |
| Subject: | XSLTProcessor recursion limit | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-122659@lists.php.net to get a copy of this message | ||
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