RFR: JDK-8321599 Data loss in AVX3 Base64 decoding [v6]
Vladimir Kozlov
kvn at openjdk.org
Wed Jan 3 18:39:02 UTC 2024
On Wed, 20 Dec 2023 16:28:03 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.
>
> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>
> - Merge branch 'openjdk:master' into Base64-fix
> - Updated copyright year
> - Updated copyright year
> - Revert code size change - wa for an experiment only.
> - Added some comments to the test
> - Merge branch 'openjdk:master' into Base64-fix
> - Merge branch 'Base64-fix' of https://github.com/asgibbons/jdk into Base64-fix
> - Merge branch 'openjdk:master' into Base64-fix
> - Added tests for proper length and padding checks
> - Fix for JDK-8321599
Looks reasonable. Please, update copyright year to 2024 in source file and test.
-------------
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17039#pullrequestreview-1802869126
More information about the hotspot-compiler-dev
mailing list