Right, with a closer look, it does require multiple threads to trigger
this problem.
Valerie
On 3/31/2020 6:10 PM, Weijun Wang wrote:
On Apr 1, 2020, at 4:01 AM, Valerie Peng <[email protected]> wrote:
Hi Alexey,
Good catch, thanks for the report, I will review it.
On a first look, it seems that this is more about the clone() method of the
SHA-3 impl missed copying/cloning an internal field.
Given that this is about SUN provider, I've modified the synopsis accordingly
and move the priority up to P3.
It may not take multi-thread to reproduce this? If so, we can simplify the
regression test.
Looks like a must:
private void keccak() {
// convert the 200-byte state into 25 lanes
bytes2Lanes(state, lanes);
// process the lanes through step mappings
for (int ir = 0; ir < NR; ir++) {
smIota(smChi(smPiRho(smTheta(lanes))), ir);
}
// convert the resulting 25 lanes back into 200-byte state
lanes2Bytes(lanes, state);
}
One object's lanes can only be used by another if this method is called by
multiple threads at the same time.
--Max
Regards,
Valerie
On 3/31/2020 11:27 AM, Alexey Bakhtin wrote:
Hi All,
Please review fix for SHA3 message digests thread safety.
Issue reproduced on the JDK11, JDK13 and JDK14
JTREG test is provided in the patch
JBS: https://bugs.openjdk.java.net/browse/JDK-8241960
Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/
Regards
Alexey
