Described issues was accepted into Oracle JDK issues: 1) SunNativeProvider.INSTANCE initialization: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073 2) Uninitialized cb->initiator_address: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630
(fixing patches are included in reports too) On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina <jkal...@redhat.com> wrote: > Hi, I was just able to prepare usable reproducer (attaching in ZIP file) > and fixing patch of JDK (attaching too). > Before I was able to make my usecase working, I has found second issue too > - I has included it too. > > Issues and their reproducing: > > 1) already described problem of wrong initialized > SunNativeProvider.INSTANCE > > This can be reproduced by recreating GSSManager before createGSSContext - > ProviderList.factories > will be initialized as part of initSecContext/acceptSecContext which will > cause using wrong initialized > SunNativeProvider.INSTANCE and described exception. > > 2) when channel binding is used SIGSEGV occure > > This can be reproduced by setting channel binding without > initAddr/acceptAddr. > This is caused by sending uninitialized (with random length) > cb->initiator_address from JDK to the kerberos. > (It is used by krb library for messages checksum calculation even when > addrtype is GSS_C_AF_NULLADDR.) > > Attached reproducer-gss.zip reproduces both issues and attached patch > fixes both. > > I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat) > > This issue affect both tested JDKs, JKD8u121 and upstream JDK9 from > mercurial master. > > Thanks, > Jan > > On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng <valerie.p...@oracle.com> > wrote: > >> >> I will take a look. Do you happen to have a test case that I can >> reproduce the issue? >> Thanks, >> Valerie >> >> >> On 12/14/2017 9:20 AM, Jan Kalina wrote: >> >> Attaching patch, which fixes described issue for me. >> >> On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina <jkal...@redhat.com> wrote: >> >>> I has found bug in SunNativeProvider: >>> >>> When debug messages are enabled, JDK confirms GSS library was loaded >>> with mechs: >>> >>> [GSSLibStub_init] libName=/usr/lib64/libgssapi_krb5.so.2.2 >>> SunNativeGSS: Loaded GSS library: /usr/lib64/libgssapi_krb5.so.2.2 >>> SunNativeGSS: Native MF for 1.2.840.113554.1.2.2 >>> SunNativeGSS: Native MF for 1.3.6.1.5.2.5 >>> SunNativeGSS: Native MF for 1.3.6.1.5.5.2 >>> >>> But when I try to use it, it claims mechanism with given OID are not >>> supported: >>> >>> GSSException: Provider SunNativeGSS does not support mechanism >>> 1.2.840.113554.1.2.2 >>> at java.security.jgss/sun.security.jgss.ProviderList.getMechFac >>> tory(ProviderList.java:253) >>> at java.security.jgss/sun.security.jgss.ProviderList.getMechFac >>> tory(ProviderList.java:209) >>> at java.security.jgss/sun.security.jgss.GSSManagerImpl.getMecha >>> nismContext(GSSManagerImpl.java:234) >>> at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe >>> cContext(GSSContextImpl.java:337) >>> at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe >>> cContext(GSSContextImpl.java:302) >>> >>> *When I has try to debug it, I has found the SunNativeProvider is >>> created in two instances:* >>> >>> First instance is created on initialization of >>> SunNativeProvider.INSTANCE, but it is BEFORE >>> the mechs are passed into SunNativeProvider.MECH_MAP. The second >>> instance is created >>> correctly in ProviderList constructor. >>> >>> The problem is, in some situations is used the too soon created >>> SunNativeProvider.INSTANCE, >>> so the to call throws exception above. >>> >>> *I think sufficient fix would be to move SunNativeProvider.INSTANCE >>> declaration after* >>> *the static constructor (filling the **MECH_MAP) in SunNativeProvider >>> file.* >>> >>> Would be possible to fix this? >>> Should I send a patch? >>> >>> Thanks >>> Jan Kalina >>> >> >> >> >
