RFR: JDK-8007607

Dmitry Samersoff dmitry.samersoff at oracle.com
Fri Feb 8 18:34:37 UTC 2013


John,

> Ideas?

It's a JNI so just throw OOM.

-Dmitry


On 2013-02-08 21:38, John Zavgren wrote:
> Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is misleading,
> I can't identify anything else that seems more appropriate.
> 
> The header file: 
> /jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h defines
> GSS_C_NO_CHANNEL_BINDINGS as follows:
> #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
> 
> The symbol matches the prototype of the function:
> 
>     */*
>      * Utility routine which creates a gss_channel_bindings_t structure
>      * using the specified org.ietf.jgss.ChannelBinding object.
>      */
>     gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
>       gss_channel_bindings_t cb;
>       jobject jinetAddr;
>       jbyteArray value;
> 
>       if (jcb == NULL) {
>         return GSS_C_NO_CHANNEL_BINDINGS;
>       }
>         cb = malloc(sizeof(struct gss_channel_bindings_struct));
> 
>         if(cb == NULL)
>             return  GSS_C_NO_CHANNEL_BINDINGS;*
> 
> There doesn't appear to be anything in our set of options that is more
> suggestive of a memory allocation failure and the symbol:
> GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
> 
> Ideas?
> 
> On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
>> John,
>>
>> Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this case.
>>
>> I'm second to Valerie - it's better to throw OOM
>>
>> -Dmitry
>>
>>
>> On 2013-02-06 03:44, John Zavgren wrote:
>>> Greetings:
>>>
>>> I modified the native code to eliminate potential memory loss and crashes by checking the return values of malloc() and realloc() calls.
>>>
>>> The webrev image of these changes is visible at:
>>> http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
>>>
>>> Thanks!
>>> John Zavgren
>>>
>>
> 
> 
> -- 
> John Zavgren
> john.zavgren at oracle.com
> 603-821-0904
> US-Burlington-MA
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer



More information about the security-dev mailing list