On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <[email protected]> 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 [email protected] (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3206134625
