RFR: JDK-8321599 Data loss in AVX3 Base64 decoding [v7]

Scott Gibbons sgibbons at openjdk.org
Wed Jan 3 19:51:02 UTC 2024


> 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 incrementally with one additional commit since the last revision:

  Fixed copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17039/files
  - new: https://git.openjdk.org/jdk/pull/17039/files/ba60ac59..5f0e0d59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17039&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17039&range=05-06

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17039/head:pull/17039

PR: https://git.openjdk.org/jdk/pull/17039


More information about the hotspot-compiler-dev mailing list