RFR: JDK-8321599 Data loss in AVX3 Base64 decoding
Evgeny Astigeevich
eastigeevich at openjdk.org
Fri Dec 8 22:54:12 UTC 2023
On Fri, 8 Dec 2023 20:56:52 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:
> Fix for looking for padding characters within the encoded string. Was not adding start offset to length, so was looking at potentially freed or uninitialized memory.
>
> Tested teir1 and with testcase supplied with JBS issue.
>
> The 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.
@asgibbons, am I correct the problem is that padding '=' characters were not found and not processed. This happens because a source offset is not taken into account.
A test is:
A, B: String
Buf: ByteBuffer
C := base64_encode(A) + base64_encode(B) # encode(B) should have '=' or '=='
put C in Buf
A' := base64_decode(Buf)
B' := base64_decode(Buf)
assert(A.equals(A'))
assert(B.equals(B'))
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17039#issuecomment-1847942366
More information about the hotspot-compiler-dev
mailing list