Repository navigation
PHP Fatal error: Maximum function nesting level of '256' reached, aborting! Protocol/Parser.php on line 293 #114
Description
When feed invalid data to Parser, we meet the fatal error.
Test data: hex2bin('80000000016db558016de4c8000000000000000400000001461fffff000005dc000020000000000137cdfa4000000000')
It is caused by the call between readLabels and getCompressedLabel
PHP 242. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 243. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 244. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 245. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 246. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 247. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 248. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 249. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 250. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 251. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 252. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 253. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 254. React\Dns\Protocol\Parser->readLabels($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:273
PHP 255. React\Dns\Protocol\Parser->getCompressedLabel($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:245
PHP 256. React\Dns\Protocol\Parser->getCompressedLabelOffset($data = *uninitialized*, $consumed = *uninitialized*) Protocol/Parser.php:272
private function readLabels($data, $consumed)
{
$labels = array();
while (true) {
if ($this->isEndOfLabels($data, $consumed)) {
$consumed += 1;
break;
}
if ($this->isCompressedLabel($data, $consumed)) {
list($newLabels, $consumed) = $this->getCompressedLabel($data, $consumed);
$labels = array_merge($labels, $newLabels);
break;
}
Activity
clue commentedon Nov 1, 2018
@wxiaoguang Thanks for reporting and providing the test case! I can confirm this bug and will look into this 👍
Out of interest, where does this data come from? What (part of a) message does it represent?
wxiaoguang commentedon Nov 2, 2018
I am using ReactDns to parse the sniffed logs of tcpdump. There are many non-dns traffics on port 53.
Besides this fatal error, there are also many E_ERROR/E_WARNING/E_NOTICE errors when using ReactDns to parse invalid data. These errors are mainly caused by unchecked array access,
unpackinsufficiency data, invalidinet_pton, etc. I can ignore these non-fatal errors, but I must bypass this fatal error to complete my work :D (I just made a very very dirty hack to bypass this fatal error: use astatic $depthto count the recursion calls, whendepthis big enough, return an error).clue commentedon Nov 5, 2018
@wxiaoguang Again, thank you for reporting and giving this background info!
We've just fixed this fatal error when parsing malformed response messages with #115 and I've filed #117 to fix any non-fatal errors when parsing malformed response messages. Once this PR is merged, you should no longer see any of the parsing errors you've mentioned.
holtkamp commentedon Sep 15, 2020
It seems I have encountered this problem as well when crawling a big XML sitemap on a daily basis using https://github.com/dpovshed/octopus
The challenge is: it does not occur every day, so I will try to gather some more information. I have the feeling that it happens when (multiple) invalid domains are crawled, for example:
https://crazySubDomainWhichDoesNotExist.example.com
https://crazySubDomainWhichDoesNotExist2.example.com
https://crazySubDomainWhichDoesNotExistN.example.com
@clue do you have any advise on where I can start looking / which information needs to be collected?
clue commentedon Sep 16, 2020
@holtkamp Thanks for reporting, this shouldn't have happened!
I don't think this is related to the original issue discussed here, can you file this as a separate ticket?
Ideally, the stack trace should include method arguments or a Wireshark/tcpdump trace would help a lot to trace this down.
holtkamp commentedon Sep 16, 2020
@clue sure, first I will investigate further and check whether "ensuring the sitemap only contains valid links" prevents the issue from occurring, that would already narrow the possible source of the problem down a bit.
clue commentedon Sep 24, 2020
@holtkamp I've managed to reproduce and fix this for malformed DNS response messages via #169. This only affects malformed/crafted DNS responses, I don't see how this could affect a valid DNS response message that would occur in the wild. Perhaps you can give this a try and see if this solves your problem?
holtkamp commentedon Sep 24, 2020
@clue thanks for the quick follow-up. I did not have time to dive into this in detail, but I did collect some additional error messages which contain some CLUEs 😄 :
Unfortunately the first parameter of Parser::readLabels() in the error message is truncated, but maybe it helps in confirming that your suggested fix works?
I will use https://github.com/clue-labs/dns/tree/compression-recurse, monitor the daily crawls and report back here.
clue commentedon Sep 24, 2020
@holtkamp The second argument in the trace is interesting, it suggests it finds a compressed DNS pointer that points to itself, thus leading to the infinite recursion. I don't see this specific scenario covered in the specs (https://tools.ietf.org/html/rfc1035#section-4.1.4), but it's my understanding this should be an invalid pointer that should never happen in the wild. The updated version would successfully reject the promise to show an invalid response message in this case.
If you can reproduce this, please let me know the hostname and/or DNS server in question (here or DM) so I can see how others handle this situation.
holtkamp commentedon Sep 25, 2020
@clue it seems #169 indeed prevents the problem from occurring 🚀
Will keep monitoring and report my findings here after the weekend!
BTW: kudos that you understand and implement such "low-level" protocols: https://tools.ietf.org/html/rfc1035#section-4.1.4 🤓
holtkamp commentedon Sep 28, 2020
@clue the sitemap crawls during last weekend did not have any problems anymore, so I would "assume" #169 fixes the issue indeed. I do not have hard evidence other than "no errors occurred", will keep monitoring, but +1 for merging it to master and tagging a new release 😉
holtkamp commentedon Oct 28, 2020
@clue FYI: we have been monitoring the daily sitemap crawls and no more problems have occurred for a month.
Will coming Friday be release-day for
1.5.0? 😇holtkamp commentedon Nov 12, 2020
@clue don't want to harass, but this probably slipped from your radar?
clue commentedon Nov 14, 2020
@holtkamp Don't worry, didn't forget about this one and will get back to this as soon as time permits 👍
Currently working on a number of higher priority (paid) projects, but will look into the release afterwards.