Bug #75236 [Com]: infinite loop when printing an error-message

Edit report at https://bugs.php.net/bug.php?id=75236&edit=1 ID: 75236 Comment by: lzsiga at freemail dot c3 dot hu Reported by: lzsiga at freemail dot c3 dot hu Summary: infinite loop when printing an error-message Status: Closed Type: Bug Package: Reproducible crash Operating System: AIX, Linux PHP Version: 7.1.9 Assigned To: ajf Block user comment: N Private report: N New Comment: Hi, thank you all for the quick fix! Speaking of character-encodings, I'd like to ask something: does PHP support any character-seta that aren't ASCII-compatible (i.e.: there might be a byte between 0x00 and 0x7f that isn't ASCII-code, but a part of a sequence), like UCS2, UTF-16 or UTF-16? (I really hope the answer is a 'no';) Previous Comments: ------------------------------------------------------------------------ [2017-09-20 23:06:36] ajf@php.net Automatic comment on behalf of ajf@ajf.me Revision: http://git.php.net/?p=php-src.git;a=commit;h=418f97443aa44644bdf81b96fb726518754724f5 Log: Fix bug #75236 ------------------------------------------------------------------------ [2017-09-20 22:18:48] ajf@php.net Argh, I'm sorry about this, I probably should have tested that fix more than I did. I'm looking into this now. ------------------------------------------------------------------------ [2017-09-20 22:00:39] cmb@php.net > instead of 'htmlentities' 'htmlspecialchars' should be called That can cause issues if the string is encoded differently than what the output expects. > htmlspecialchars only deals with ASCII characters like < > & ' " Applying htmlspecialchars() on an arbitrary encoding assuming it would be ASCII compatible causes issues. Consider an UTF-16 encoded ļ (U+0131). Anyhow, the behavioral change introduced by fixing bug #74725 appears to be a severe bug, since htmlspecialchars() segfaults due to infinite recursion for any unsupported default_charset, if html_errors is enabled: <?php ini_set('html_errors', true); ini_set('default_charset', 'ISO-8859-2'); htmlentities('foo', ENT_COMPAT, 'ISO-8859-2'); A possible solution might be to temporarily change the default_charset to UTF-8 while calling php_error_docref()[1], and to remove charset_hint from the message, to ensure that we're really dealing with UTF-8 (actually, ASCII) here. Andrea, could you please have a look at this issue? [1] <https://github.com/php/php-src/blob/php-7.1.9/ext/standard/html.c#L463-L464> ------------------------------------------------------------------------ [2017-09-20 20:23:30] lzsiga at freemail dot c3 dot hu Well, yes, my fault; what I should have suggested is that instead of 'htmlentities' 'htmlspecialchars' should be called, with hardcoded 'charset='ISO-8859-1' (or 'ASCII' if there is such an option -- htmlspecialchars only deals with ASCII characters like < > & ' " ) ------------------------------------------------------------------------ [2017-09-20 17:01:12] cmb@php.net I can confirm this issue. It happens for all unsupported "charsets", i.e. for those that htmlentities() would throw a respective warning. See <https://github.com/php/php-src/blob/php-7.1.9/ext/standard/html.c#L448-L467>. > The problem could be solved if htmlentities didn't verify UTF8-validity and > silently ignored 'charset' parameter. That would cause other issues, though. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75236 -- Edit this bug report at https://bugs.php.net/bug.php?id=75236&edit=1