RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0

Seán Coffey sean.coffey at oracle.com
Fri Aug 25 13:28:54 UTC 2017


Tony pointed out off-list that the change to encodeISOArray() might not 
work.

"I'm not certain the change to encodeISOArray() is not going to work. In 
8, that method can be replaced by an intrinsic and miss your additional 
check.  Unlike in 9 where implEncodeISOArray() is intrinsfied.  It maybe 
best to backport the method name change done in 9 too."

I replied :

"That's a fair point Tony. Without risking too much change for 
jdk8u-dev, would it be ok to ensure that the len value is not <= 0 
before we call the method itself. There are only two call sites. 
Refactoring of various methods too place in JDK 9 and introduced 
implEncodeISOArray in that class. [1]. I think the change I'm proposing 
is just as useful and safer :

new webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u.02/webrev/"

The security-dev list got dropped. Re-adding here.

Regards,
Sean.

On 16/08/17 13:14, Seán Coffey wrote:
>
> Looking to backport this fix to jdk8u-dev. The bug report is not 
> public but the JDK 9 review thread captures the details. The fix is 
> similar. Some extra intrinsics work in jdk9 wasn't applicable for the 
> jdk8u-dev port.
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044560.html 
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u/webrev/
> -- 
> Regards,
> Sean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170825/5a22410f/attachment.htm>


More information about the security-dev mailing list