I cannot reproduce the access violation (neither with the given
code, nor when I replace the ² with 2, nor when I just remove the
²).  And neither does the assertion trigger in a debug build for
me (it won't trigger in release builds anyway).

Could you please fix/clarify the test script?

I digged a little bit into this and it appears to be a system-dependent problem.

When running the script with Windows7 SP1 or Windows Server 2016 (1607), the script says "Warning: Use of undefined constant �6483605105519922841849335928742092 - assumed '�6483605105519922841849335928742092'" and crashes.

Note the non printable character here.

When running the script with Windows 10 (1809), the scipt says "Warning: Use of undefined constant 6483605105519922841849335928742092 - assumed '6483605105519922841849335928742092'"  and does not crash.

Note that there is no unprintable character here.

So it appears to me that depending on the Windows setup, php seem to ignore the '²', or not. If it is not ignored, an access violation occurs.

If you need a test setup in which the bug can be reproduced go to
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

and download the "IE11 on Win7 (x86)" machine.

You need to install VC Redistributables, but then you are good to go.

Hmm, pretty strange that the behavior depends on the Windows
version, but of course, possible.

Could you please post what you get when running

  <?php
  var_dump(²6483605105519922841849335928742092);

Note that the charset/character encoding may very well matter
here.

C:\Users\IEUser>C:\Users\IEUser\Desktop\php-7.4.0-Win32-vc15-x64\php.exe C:\Users\IEUser\Desktop\text.php

Warning: Use of undefined constant ²6483605105519922841849335928742092 - assumed '²6483605105519922841849335928742092' (this will throw an Error in a future ver
sion of PHP) in C:\Users\IEUser\Desktop\text.php on line 3
string(35) "²6483605105519922841849335928742092"

Thanks!  That proves that the ² is encoded as a single byte (so
it's not any Unicode encoding).

While I still not have been able to reproduce the access
violation, it's pretty clear that the code may allow for that,
because it uses isdigit()[1] which is locale-dependent, to check
for digits, but only expects decimal ASCII digits[2].  So
depending on the current locale, on char signedness, and perhaps a
broken isdigit() implementation, this can lead to all kinds of
issues.

Therefore, I'm tentatively re-classifying as security issue.

Suggested patch: <https://gist.github.com/cmb69/4796c38a08cb17aef5daaa57bcf75041>.
For PHP-7.3+ also PHP-7.3+.patch has to be applied.

Stas, could you please handle it from here?  If it's not security
issue, please assign back to me.

[1] <https://github.com/php/php-src/blob/php-7.4.0/ext/bcmath/libbcmath/src/str2num.c#L59-L61>
[2] <https://github.com/php/php-src/blob/php-7.4.0/ext/bcmath/libbcmath/src/bcmath.h#L61-L64>

I am not sure I understand the issue completely - let's say isdigit misclassified the character, what could happen because of that? Why it is different from just having non-digit passed to the function?

If a non-digit is passed to the function, E_WARNING is raised, and
the number is taken as zero.  If a digit, which is not an ASCII
digit, is passed, it is stored as `digit - '0'` (BCMath stores
each decimal digit in a full byte), and as such has a value < 0 or
> 9; libbcmath expects all bytes to be in range [0,9], though.