JDK-8321599 : Data loss in AVX3 Base64 decoding
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,22
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2023-12-08
  • Updated: 2024-02-16
  • Resolved: 2024-01-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 21 JDK 22 JDK 23
17.0.11Fixed 21.0.3-oracleFixed 22Fixed 23 b04Fixed
Related Reports
Relates :  
JDK-8268276 - Base64 Decoding optimization for x86 using AVX-512
Description
Base64 appears to give different (wrong) results in some rare cases when AVX3 is enabled. This has been observed in one of our services.

The attached reproducer fails reliably with -XX:UseAVX3 on my host with these CPU details (an AWS EC2 c6i.large instance):

```
vendor_id       : GenuineIntel
cpu family      : 6
model           : 106
model name      : Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
stepping        : 6
```

The same reproducer passes reliably with `-XX:UseAVX=2`.

```
java -XX:UseAVX=2 Base64Avx3.java
Test complete, no invalid decodes detected

java -XX:UseAVX=3 Base64Avx3.java
Exception in thread "main" java.lang.IllegalStateException: Mismatch for iouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wABAgMEBQYHCAkKCwwNDg8QERITFBU=

Expected:
8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15

Actual:
8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14
	at Base64Avx3.decodeAndCheck(Base64Avx3.java:68)
	at Base64Avx3.main(Base64Avx3.java:55)
```

It may be related to JDK-8268276.

Note also that the bug requires that the CPU supports avx512bw *and* avx512vbmi.
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2100 Date: 2024-01-04 10:23:52 +0000
04-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/122 Date: 2024-01-04 09:48:48 +0000
04-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/28 Date: 2024-01-04 06:13:11 +0000
04-01-2024
Changeset: 13c11487 Author: Scott Gibbons <sgibbons@openjdk.org> Committer: Sandhya Viswanathan <sviswanathan@openjdk.org> Date: 2024-01-04 01:36:28 +0000 URL: https://git.openjdk.org/jdk/commit/13c11487f7126a370d9ce8e62f661ea83eedefe6
04-01-2024
[jdk21u-fix-request] Approval Request from olivergillespie Clean backport, fairly simple fix with reproducer for important issue (incorrect result from intrinsic).
04-01-2024
[jdk17u-fix-request] Approval Request from olivergillespie Nearly clean backport, fairly simple fix with reproducer for important issue (incorrect result from intrinsic).
04-01-2024
ILW = Incorrect result of compiled code, Base64 decoding with AVX3, -XX:DisableIntrinsic=_base64_decodeBlock = HMM = P2
03-01-2024
Security issues have been evaluated and resolved. Re-opening the PR.
19-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17039 Date: 2023-12-08 20:56:52 +0000
08-12-2023
I have found the problem and am testing the fix. This problem will only occur when all of the following are true: 1. The source offset of the string to be decoded is != 0. 2. The characters at the beginning of the string (minus the offset) plus the string length mod 64 are either "=" or "==". 3. The string is >= 32 characters. 4. The string is not MIME encoded. If any of these conditions are not met, the decode works as expected. This was due to omitting the source offset of the string when checking for padding characters.
08-12-2023
I'd argue that base64 a very basic and common algorithm and wrong bas64 encoding/decoding can easily lead to undetected data loss or corruption. Because this can happen in the LTS releases 17 & 21, I think it is justified to raised the priority to P2.
08-12-2023
Can be worked around with: ``` -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_base64_decodeBlock ```
08-12-2023
I'll take a look at it today. Thanks for the heads-up.
08-12-2023
Adding [~jbhateja] to the issue.
08-12-2023
@sgibbons Are you able to take a look at this? It seems it may be related to JDK-8268276.
08-12-2023