RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3]

Wed Sep 10 13:23:27 UTC 2025

On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip)
>> NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE.
>> 
>> 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused code
>  - removed the commented out code

I have built and tested now.

Before:

krb5[0x3|main|Krb5Context.java:893|2025-09-10 15:18:00.264]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 25 87 e1 db 30 47 02 01 04 63 25 04 00 0a 01 00 0a 01 03 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 05 04 03 31 2e 31 a0 1b 30 19 04 17 32 2e 31 36 2e 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 2e 32 0d 18 15 c7 e1 41 c1 96 ab 8d fe a1 ]

-> DEMCHADC08A.ad001.siemens.net:636

0000: 30 05 02 01 05 42 00                               0....B.

krb5[0x18|Thread-0|Krb5Context.java:893|2025-09-10 15:18:00.287]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 25 87 e1 dc 30 05 02 01 05 42 00 0a ea 9f fe c8 6d f6 3f 23 e9 69 21 ]

-> DEMCHADC08A.ad001.siemens.net:636

0000: 30 06 02 01 06 50 01 04                            0....P..

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "org.ietf.jgss.GSSContext.wrap(byte[], int, int, org.ietf.jgss.MessageProp)" because "this.secCtx" is null
        at jdk.security.jgss/com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:140)
        at java.naming/com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89)
        at java.naming/com.sun.jndi.ldap.Connection.abandonRequest(Connection.java:582)
        at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:472)
        at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:664)
        at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:587)
        at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013)
        at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873)
        at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
        at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
        at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:346)
        at DirTest.main(DirTest.java:119)

with the change:

krb5[0x3|main|Krb5Context.java:893|2025-09-10 14:42:44.627]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 7f 30 47 02 01 04 63 25 04 00 0a 01 00 0a 01 03 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 05 04 03 31 2e 31 a0 1b 30 19 04 17 32 2e 31 36 2e 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 2e 32 51 a1 96 a3 b7 5c e5 fe 2c 94 91 ed ]

-> DEMCHADC08A.ad001.siemens.net:636

0000: 30 05 02 01 05 42 00                               0....B.

krb5[0x18|Thread-0|Krb5Context.java:893|2025-09-10 14:42:44.646]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 80 30 05 02 01 05 42 00 94 98 24 f3 27 34 a0 af e7 bd bf 1a ]

-> DEMCHADC08A.ad001.siemens.net:636

0000: 30 06 02 01 06 50 01 04                            0....P..

krb5[0x3|main|Krb5Context.java:893|2025-09-10 14:42:44.649]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 81 30 06 02 01 06 50 01 04 df 16 7c f1 ad fe 64 de bb 28 24 c7 ]
Exception in thread "main" javax.naming.CommunicationException: LDAP connection has been closed [Root exception is java.io.IOException: LDAP connection has been closed]; remaining name ''
        at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:484)
        at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:684)
        at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:607)
        at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013)
        at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873)
        at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
        at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
        at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:346)
        at DirTest.main(DirTest.java:119)
Caused by: java.io.IOException: LDAP connection has been closed
        at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:145)
        at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:460)
        ... 10 more

@weibxiao Is the security context still cleanly disposed?

>From my superficial testing this looks good now.

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

Changes requested by michael-o at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3206134625