> Fatal error: Possible integer overflow in memory allocation (0 + 32)

1. Multiple consecutive underscores are not supposed to be allowed
2. Parser is matching HNUM as only the "0x0"
3. HNUM code skips *all* leading zeros and underscores, goes beyond "0x0" length assumed, len underflows

Is something wrong with the re2c regex? It seems strange that the BNUM/HNUM code even runs when there are invalid characters in the literal. Do we have to duplicate syntax checks in the BNUM/HNUM code?

It seems that multiple consecutive numeric separators aren't the only problem. If I use any invalid character after 0x0_ or 0b0_ I get the following fatal error:

Fatal error: Possible integer overflow in memory allocation (1 * 18446744073709551615 + 1).

Here's my initial attempt at a fix. I'm not sure if it's the right approach or not, but it does produce a nicer error message!


 Zend/zend_language_scanner.l | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/Zend/zend_language_scanner.l b/Zend/zend_language_scanner.l
index 2e21ee7952..901ae1085a 100644
--- a/Zend/zend_language_scanner.l
+++ b/Zend/zend_language_scanner.l
@@ -1776,8 +1776,16 @@ NEWLINE ("\r"|"\n"|"\r\n")
 
 	/* Skip any leading 0s */
 	while (*bin == '0' || *bin == '_') {
+		if (len < 1) {
+			zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0);
+			if (PARSER_MODE()) {
+				RETURN_TOKEN(T_ERROR);
+			}
+			RETURN_TOKEN_WITH_VAL(T_LNUMBER);
+		} else {
+			--len;
+		}
 		++bin;
-		--len;
 	}
 
 	contains_underscores = (memchr(bin, '_', len) != NULL);
@@ -1893,8 +1901,16 @@ NEWLINE ("\r"|"\n"|"\r\n")
 
 	/* Skip any leading 0s */
 	while (*hex == '0' || *hex == '_') {
+		if (len < 1) {
+			zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0);
+			if (PARSER_MODE()) {
+				RETURN_TOKEN(T_ERROR);
+			}
+			RETURN_TOKEN_WITH_VAL(T_LNUMBER);
+		} else {
+			--len;
+		}
 		++hex;
-		--len;
 	}
 
 	contains_underscores = (memchr(hex, '_', len) != NULL);

> Here's my initial attempt at a fix. I'm not sure if it's the right approach or not, but it does produce a nicer error message!

Checking the length is fine, but it should not throw an error. In this case 0x0 is still a well-formed number and _ is a well-formed label -- the actual error occurs during parsing.

Alternatively the number tokens could be redefined to support arbitrary _ and make cases like __ or trailing _ an explicit error. That will give nicer error messages, but this needs a corresponding change in the regexes to avoid inconsistent behavior.