[Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory
Wei-Jun Wang
weijun.wang at oracle.com
Wed Aug 20 16:44:05 UTC 2025
Not an LDAP expert, but I see that abandonRequest() still wants to write into outStream. If the SASL/GSS context is already disposed by now what stream should this be? Should it be reverted back to the raw stream?
Thanks,
Weijun
> On Jun 12, 2025, at 12:42, Osipov, Michael (IN IT IN) <michael.osipov at innomotics.com> wrote:
>
>> Hi Michael,
>> Please share a working copy of the code to duplicate the failure scenario of NPE related to Connection.java. BTW, I checked the stack trace posted on April 28 it did not clearly show Connection::cleanup got called. Was there something missed?
>
> Hi Weibing,
>
> apologies, it took me some time to respond. Here is the Java code in question: https://gist.github.com/michael-o/8cff749d3ce5536bf70a16a64819cf10. Please also find here some screenshots (https://people.freebsd.org/~michaelo/ad-gssapi-tls-npe/) from my debugger showing the cause.
>
> There is, indeed, something you missed: The Connection object is run asynchronously is a separate thread. ::run() invokes the SASL input stream which throws an IOE because the SASL receive buffer size is too large. The exception is caught and swallowed. finally{} is called, it calls ::cleanup(). Meanwhile the LDAP client receives the connection closure from the server, the client tries to abandon the request and invokes the SASL client which is already disposed by the connection. Therefore you don't see the Connection::cleanup() method in the stack trace. If you pay a close look at the output of ldapsearch(1) you will see that there are two errors: (1) the buffer size mismatch and (2) the connection closure from the server. The first issue causes the second to fail in JNDI/LDAP.
>
> Michael
More information about the security-dev
mailing list