RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234

[David Holmes]

Hi Mauro,

On 11/12/2020 9:48 pm, Mauro Lacy wrote:
> On Fri, 11 Dec 2020 11:33:41 GMT, Mauro Lacy <github.com+11656534+maurolacy at openjdk.org> wrote:
>>> I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem:
>>>
>>> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c
>>
>> I've taken a look and yes, I think you're right. The line
>> `        (*env)->ReleasePrimitiveArrayCritical(env, jOut, outBufP, JNI_COMMIT);`
>>
>> should probably use `JNI_ABORT` if there's an error, and `0` if it's a normal cleanup.
>>
>> On second look, `0` looks like the obvious choice. If there's a jump due to an error, `outBufP` will be `NULL`, and the line wouldn't be executed in the first place.
> 
> I'll send a PR for that cryptoki fix too, if you like. I'll now try to register into the issue tracker, so I can create a proper issue for it.

You can't "register" for the OpenJDK JBS, you are only granted write 
access once you have Author status in the OpenJDK project. I will file 
an issue but the security-libs folk will need to decide what to do about it.

With regards to an earlier comment regarding the inconsistent behaviour 
- yes this is only a -Xcheck:jni issue because it is only in that case 
that any buffer copying every occurs and so freeing actually does 
something. Otherwise hotspot never copies and the release mode is 
irrelevant with regard to freeing anything.

Again I will look further into this, on Monday.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1697
>