JDK-8257225 : UUID#fromString Accepts Invalid Input
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 8,11,16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2020-11-25
  • Updated: 2021-03-10
  • Resolved: 2020-12-02
Related Reports
Cloners :  
JDK-8257635 - UUID#fromString Accepts Invalid Input
Relates :  
JDK-8257635 - UUID#fromString Accepts Invalid Input
Relates :  
JDK-8159339 - UUID:fromString() parses incorrect strings without error
Description
A DESCRIPTION OF THE PROBLEM :
All of the following are parsed by UUID#fromString but are actually invalid:

0-0-0-0-0
+0000000-0000-0000-0000-000000000000
00000000-+000-0000-0000-000000000000
00000000-0000-+000-0000-000000000000
00000000-0000-0000-+000-000000000000
00000000-0000-0000-0000-+00000000000
0-0-0-0-0000000000000000000000000000
0000000000000000000000000000-0-0-0-0

Additionally the following non-hexadecimal chars are being accepted as well:

\u0660
\u0661
\u0662
\u0663
\u0664
\u0665
\u0666
\u0667
\u0668
\u0669
\u06F0
\u06F1
\u06F2
\u06F3
\u06F4
\u06F5
\u06F6
\u06F7
\u06F8
\u06F9
\u07C0
\u07C1
\u07C2
\u07C3
\u07C4
\u07C5
\u07C6
\u07C7
\u07C8
\u07C9
\u0966
\u0967
\u0968
\u0969
\u096A
\u096B
\u096C
\u096D
\u096E
\u096F
\u09E6
\u09E7
\u09E8
\u09E9
\u09EA
\u09EB
\u09EC
\u09ED
\u09EE
\u09EF
\u0A66
\u0A67
\u0A68
\u0A69
\u0A6A
\u0A6B
\u0A6C
\u0A6D
\u0A6E
\u0A6F
\u0AE6
\u0AE7
\u0AE8
\u0AE9
\u0AEA
\u0AEB
\u0AEC
\u0AED
\u0AEE
\u0AEF
\u0B66
\u0B67
\u0B68
\u0B69
\u0B6A
\u0B6B
\u0B6C
\u0B6D
\u0B6E
\u0B6F
\u0BE6
\u0BE7
\u0BE8
\u0BE9
\u0BEA
\u0BEB
\u0BEC
\u0BED
\u0BEE
\u0BEF
\u0C66
\u0C67
\u0C68
\u0C69
\u0C6A
\u0C6B
\u0C6C
\u0C6D
\u0C6E
\u0C6F
\u0CE6
\u0CE7
\u0CE8
\u0CE9
\u0CEA
\u0CEB
\u0CEC
\u0CED
\u0CEE
\u0CEF
\u0D66
\u0D67
\u0D68
\u0D69
\u0D6A
\u0D6B
\u0D6C
\u0D6D
\u0D6E
\u0D6F
\u0DE6
\u0DE7
\u0DE8
\u0DE9
\u0DEA
\u0DEB
\u0DEC
\u0DED
\u0DEE
\u0DEF
\u0E50
\u0E51
\u0E52
\u0E53
\u0E54
\u0E55
\u0E56
\u0E57
\u0E58
\u0E59
\u0ED0
\u0ED1
\u0ED2
\u0ED3
\u0ED4
\u0ED5
\u0ED6
\u0ED7
\u0ED8
\u0ED9
\u0F20
\u0F21
\u0F22
\u0F23
\u0F24
\u0F25
\u0F26
\u0F27
\u0F28
\u0F29
\u1040
\u1041
\u1042
\u1043
\u1044
\u1045
\u1046
\u1047
\u1048
\u1049
\u1090
\u1091
\u1092
\u1093
\u1094
\u1095
\u1096
\u1097
\u1098
\u1099
\u17E0
\u17E1
\u17E2
\u17E3
\u17E4
\u17E5
\u17E6
\u17E7
\u17E8
\u17E9
\u1810
\u1811
\u1812
\u1813
\u1814
\u1815
\u1816
\u1817
\u1818
\u1819
\u1946
\u1947
\u1948
\u1949
\u194A
\u194B
\u194C
\u194D
\u194E
\u194F
\u19D0
\u19D1
\u19D2
\u19D3
\u19D4
\u19D5
\u19D6
\u19D7
\u19D8
\u19D9
\u1A80
\u1A81
\u1A82
\u1A83
\u1A84
\u1A85
\u1A86
\u1A87
\u1A88
\u1A89
\u1A90
\u1A91
\u1A92
\u1A93
\u1A94
\u1A95
\u1A96
\u1A97
\u1A98
\u1A99
\u1B50
\u1B51
\u1B52
\u1B53
\u1B54
\u1B55
\u1B56
\u1B57
\u1B58
\u1B59
\u1BB0
\u1BB1
\u1BB2
\u1BB3
\u1BB4
\u1BB5
\u1BB6
\u1BB7
\u1BB8
\u1BB9
\u1C40
\u1C41
\u1C42
\u1C43
\u1C44
\u1C45
\u1C46
\u1C47
\u1C48
\u1C49
\u1C50
\u1C51
\u1C52
\u1C53
\u1C54
\u1C55
\u1C56
\u1C57
\u1C58
\u1C59
\uA620
\uA621
\uA622
\uA623
\uA624
\uA625
\uA626
\uA627
\uA628
\uA629
\uA8D0
\uA8D1
\uA8D2
\uA8D3
\uA8D4
\uA8D5
\uA8D6
\uA8D7
\uA8D8
\uA8D9
\uA900
\uA901
\uA902
\uA903
\uA904
\uA905
\uA906
\uA907
\uA908
\uA909
\uA9D0
\uA9D1
\uA9D2
\uA9D3
\uA9D4
\uA9D5
\uA9D6
\uA9D7
\uA9D8
\uA9D9
\uA9F0
\uA9F1
\uA9F2
\uA9F3
\uA9F4
\uA9F5
\uA9F6
\uA9F7
\uA9F8
\uA9F9
\uAA50
\uAA51
\uAA52
\uAA53
\uAA54
\uAA55
\uAA56
\uAA57
\uAA58
\uAA59
\uABF0
\uABF1
\uABF2
\uABF3
\uABF4
\uABF5
\uABF6
\uABF7
\uABF8
\uABF9
\uFF10
\uFF11
\uFF12
\uFF13
\uFF14
\uFF15
\uFF16
\uFF17
\uFF18
\uFF19
\uFF21
\uFF22
\uFF23
\uFF24
\uFF25
\uFF26
\uFF41
\uFF42
\uFF43
\uFF44
\uFF45
\uFF46

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
IllegalArgumentException

FREQUENCY : always
Comments
The work to improve performance in 8196334 was only able to improve performance for conforming inputs, for other inputs it reverts to the backward compatible behavior. The behavior is the result of using Long.parseLong to convert from hex; it allows a leading sign character and any character recognized as a digit by Character.isDigit(...). Changing the behavior for prior versions would break compatibility and is a non-starter. Separately, it can be considered to break compatibility for future versions.
02-12-2020
See JDK-8159339 for prior discussion of compatibility issues with throwing new exceptions even for invalid inputs.
02-12-2020
The observations on Windows 10: JDK 8: Failed, invalid inputs accepted JDK 11: Failed. JDK 16: Failed.
28-11-2020
More information from the submitter: I've already created PR to fix the issue and it includes unit tests: https://github.com/openjdk/jdk/pull/1444/files#diff-b6963454787d11842ebaf80f917a4395d07ba269b2ac032b4c0adc2aee664512R106-R112 https://github.com/openjdk/jdk/pull/1444/files#diff-b6963454787d11842ebaf80f917a4395d07ba269b2ac032b4c0adc2aee664512R120-R123 https://github.com/openjdk/jdk/pull/1444/files#diff-b6963454787d11842ebaf80f917a4395d07ba269b2ac032b4c0adc2aee664512R126-R130 If you give non-hexadecimal char a properly formatted UUID string, it starts accepting all kinds of weird characters. See attached updated test case and how it fails on all inputs I reported. I tested this against the current JDK master, so it applies to all of the recent JDK releases.
28-11-2020
Requested a simple reproducer from the submitter.
26-11-2020