On Wed, 2 Sep 2026 12:44:06 GMT, Timofei Fedotov <[email protected]> wrote:
>> Rfc2253Parser silently accepted an empty RDN (no attributeTypeAndValue pair)
>> instead of
>> throwing InvalidNameException. Rdn.getType()/getValue() then indexed an empty
>> internal list, throwing an uncaught IndexOutOfBoundsException instead of the
>> documented
>> exception.
>>
>> Two independent entry points:
>>
>> Rdn("") - the original fuzzer-found crash.
>> LdapName("cn=x,") / LdapName.add("") - a string with a trailing , or ;,
>> which never goes
>> through Rdn(String) at all (LdapName builds the RDN directly via
>> Rfc2253Parser).
>>
>> Add one check, rdn.size() == 0, throw InvalidNameException, placed in
>>
>> Rfc2253Parser.doParse(Rdn) - the single method both paths funnel through.
>>
>> Also add a regression check that "cn=a,,cn=b" still throws as before.
>>
>>
>>
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Timofei Fedotov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add regression test
I checked Rdn.readObject/LdapName.readObject. Both re-parse the serial form via
Rfc2253Parser and already wrap InvalidNameException as StreamCorruptedException
(with a // shouldn't happen comment, since this branch was previously
unreachable). So, yes, deserializing a legacy stream produced by new Rdn("") or
an unmutated new LdapName("cn=x,") will now throw StreamCorruptedException
instead of succeeding and failing later on first getType()/getValue() call with
an uncaught IndexOutOfBoundsException.
I think, this as a compatibility improvement rather than a new risk, because
the failure moves earlier (at readObject, a checked IOException the caller
already must handle) and into an exception path the original implementation
explicitly anticipated and coded for, rather than an undocumented
RuntimeException surfacing arbitrarily later. The only streams affected are
ones that could only have been produced by the very bug this fix closes, there
is no legitimate prior state that becomes unreadable.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32648#issuecomment-5524367665
