back to all blogsSee all blog posts

CVE and many other notable bug fixes in Open Liberty 22.0.0.12

image of author
Michal Broz on Nov 22, 2022
Post available in languages: 日本語 ,

Open Liberty 22.0.0.12 provides many significant bug fixes, including one that addresses a CVE in GraphQL Java. If you’re interested in features and functionality which we have in progress, like Jakarta EE 10, MicroProfile 6, and InstantOn, take a look at the recent beta blog posts.

In Open Liberty 22.0.0.12:

Along with the new features and functions added to the runtime, we’ve also made updates to our guides.

Run your apps using 22.0.0.12

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.12</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.12,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2022-37734

7.5

Denial of service

17.0.0.3 - 22.0.0.11

Affects the mpGraphQL-1.0 and mpGraphQL-2.0 features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.12.

  • MP Reactive Messaging: NullPointerException during Kafka partition rebalance

    During partition reassignment, it’s possible for the Kafka connector for MicroProfile Reactive Messaging to not update its internal state correctly, resulting in it no longer receiving messages and a NullPointerException being logged.

    The following log messages may be seen:

    java.lang.NullPointerException
            at com.ibm.ws.microprofile.reactive.messaging.kafka.KafkaInput.lambda$wrapInMessageStream$10(KafkaInput.java:274)
            at com.ibm.ws.microprofile.reactive.messaging.kafka.KafkaInput$$Lambda$476/0x00000000c2be7230.test(Unknown Source)
            at io.smallrye.reactive.streams.stages.FilterStageFactory$$Lambda$481/0x00000000c3268d30.test(Unknown Source)
    User provided listener com.ibm.ws.microprofile.reactive.messaging.kafka.adapter.impl.ConsumerRebalanceListenerImpl failed on invocation of onPartitionsRevoked for partitions [live-partition-test-in-0]
    java.lang.NullPointerException
            at com.ibm.ws.microprofile.reactive.messaging.kafka.KafkaInput.onPartitionsRevoked(KafkaInput.java:346)
            at com.ibm.ws.microprofile.reactive.messaging.kafka.adapter.impl.ConsumerRebalanceListenerImpl.onPartitionsRevoked(ConsumerRebalanceListenerImpl.java:55)
            at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.invokePartitionsRevoked(ConsumerCoordinator.java:315)

    This issue has been resolved and the partition assignment succeeds correctly and without these errors.

  • Provide a way for Custom User Registries to use the uniqueId instead of the securityName

    When using a CustomUserRegistry and making a programmatic API call like getRemoteUser, getCallerPrincipal or getUserPrincipal, Open Liberty was incorrectly returning the securityName.

    The issue is now resolved and the getRemoteUser, getCallerPrincipal or getUserPrincipal methods correctly return the displayName.

  • AmbiguousResolutionException when same class is present twice and certain features are used

    When a class is present twice in an application and is used as a CDI managed bean and certain features are used, CDI may sometimes report an AmbiguousResolutionException.

    Caused by: org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
      - Managed Bean [class com.ibm.wssvt.acme.annuity.common.business.jaxrs.MyJAXBResolver] with qualifiers [@Any @Default],
      - Managed Bean [class com.ibm.wssvt.acme.annuity.common.business.jaxrs.MyJAXBResolver] with qualifiers [@Any @Default]

    This issue is now resolved. The same bean is no longer included twice and the exception is no longer thrown.

  • IllegalStateException in DynaCache when app server is stopping

    Sometimes while the Liberty server is shutting down with the webCache-1.0 feature enabled, an FFDC is created by a DynaCache daemon thread:

    Stack Dump = java.lang.IllegalStateException: ScheduledExecutorService service is unavailable
     at com.ibm.ws.cache.Scheduler.getScheduledExecutorService(Scheduler.java:93)
     at com.ibm.ws.cache.Scheduler.createNonDeferrable(Scheduler.java:108)
     at com.ibm.ws.cache.RealTimeDaemon.alarm(RealTimeDaemon.java:107)
     at com.ibm.ws.cache.RealTimeDaemon$2.run(RealTimeDaemon.java:111)
     at com.ibm.ws.cache.Scheduler$WrappedRunnable.run(Scheduler.java:130)
     ...

    The issue is now resolved. DynaCache no longer attempts to create a schedule when the Liberty server is stopping and the FFDC is not generated.

  • IdentityStore validate method not getting called for BasicAuthentication request

    Some Basic Authentication requests fail due to IdentityStore not being called correctly. This a result of Liberty’s BasicHttpAuthenticationMechanism using BasicAuthenticationCredential instead of UsernamePasswordCredential. That credential object is passed down to the IdentityStore validate method call as a parameter.

    The BasicAuthenticationCredential class extends the UsernamePasswordCredential.

    For this case, IdentityStore needs to have an overloaded version of the validate method to function properly. For example:

    public CredentialValidationResult validate(BasicAuthenticationCredential basicAuthenticationCredential) {
            return validate(new UsernamePasswordCredential(basicAuthenticationCredential.getCaller(), basicAuthenticationCredential.getPasswordAsString()));
        }

    The issue is now resolved and the authentication succeeds with the validate method being called and successfully validating the user.

  • EJB Handle deserialization fails with org.omg.CORBA.TRANSIENT: attempt to establish connection failed

    After deserializing an EJBHandle or HomeHandle, attempts to use the handle may fail with the following exception:

    ERROR: java.rmi.RemoteException: CORBA TRANSIENT 1095974913 No; nested exception is:
        org.omg.CORBA.TRANSIENT: attempt to establish connection failed:  vmcid: Apache minor code: 0x1  completed: No
        at org.apache.yoko.rmi.impl.UtilImpl.createRemoteException(UtilImpl.java:206)
        at [internal classes]
    Caused by: org.omg.CORBA.TRANSIENT: attempt to establish connection failed:  vmcid: Apache minor code: 0x1  completed: No
        at org.apache.yoko.orb.exceptions.Transients.create(Transients.java:85)
        at [internal classes]
        at org.apache.yoko.orb.OB.GIOPClient.access$000(GIOPClient.java:60)
        at org.apache.yoko.orb.OB.GIOPClient$1.create(GIOPClient.java:141)
        at [internal classes]
        ...

    This issue is now resolved and the method calls on the EJB (or EJBHome) work properly.

  • Uses constraint violation for org.joda.time packages

    After changing the server.xml to add features to the featureManager list, the server can fail to start with Uses constraint violation errors related to org.joda.time packages.

    30-com.ibm.ws.org.apache.wss4j.ws.security.web.2.3.0.jakarta E CWWKE0702E: Could not resolve module: com.ibm.ws.org.apache.wss4j.ws.security.web.2.3.0.jakarta [330]
      Unresolved requirement: Import-Package: org.apache.wss4j.dom.engine; version="[2.3.0,3.0.0)"
        -> Export-Package: org.apache.wss4j.dom.engine; bundle-symbolic-name="com.ibm.ws.org.apache.wss4j.ws.security.dom.2.3.0.jakarta"; bundle-version="1.0.70.202210111310"; version="2.3.0"; uses:="javax.security.auth.callback,javax.xml.datatype,javax.xml.namespace,org.apache.wss4j.common.crypto,org.apache.wss4j.common.ext,org.apache.wss4j.common.saml,org.apache.wss4j.common.token,org.apache.wss4j.common.util,org.apache.wss4j.dom,org.apache.wss4j.dom.action,org.apache.wss4j.dom.callback,org.apache.wss4j.dom.handler,org.apache.wss4j.dom.message.token,org.apache.wss4j.dom.processor,org.apache.wss4j.dom.validate,org.w3c.dom"
           com.ibm.ws.org.apache.wss4j.ws.security.dom.2.3.0.jakarta [327]
      Bundle was not resolved because of a uses constraint violation.
      org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource com.ibm.ws.org.apache.wss4j.ws.security.dom.2.3.0.jakarta [osgi.identity; osgi.identity="com.ibm.ws.org.apache.wss4j.ws.security.dom.2.3.0.jakarta"; type="osgi.bundle"; version:Version="1.0.70.202210111310"] because it is exposed to package 'org.joda.time' from resources com.ibm.ws.org.joda.time.2.9.9 [osgi.identity; osgi.identity="com.ibm.ws.org.joda.time.2.9.9"; type="osgi.bundle"; version:Version="1.0.70.202210111212"] and com.ibm.ws.org.joda.time.1.6.2 [osgi.identity; type="osgi.bundle"; version:Version="1.0.70.202210111212"; osgi.identity="com.ibm.ws.org.joda.time.1.6.2"] via two dependency chains.

    This issue is now resolved and the server starts successfully without the error.

  • Failed to parse Created TimeStamp in UsernameTokenValidator

    As a result of updating CXF, a bug has been re-introduced that causes a valid SOAP request to fail when UsernameToken does not include milliseconds.

    This issue has been resolved, and a test has been added to help ensure the regression doesn’t occur again.

  • Intermittent NPE at com.ibm.ws.security.javaeesec.cdi.extensions.HttpAuthenticationMechanismsTracker.getAuthMechs(HttpAuthenticationMechanismsTracker.java:186)

    The following NPE is produced intermittently, failing to start the application:

    [ERROR   ] CWWKZ0002E: An exception occurred while starting the application microProfileLoginConfig_MultiLayer_NotInWebXml_MpJwtInApp. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
    Exception 0 :
    java.lang.NullPointerException
    at com.ibm.ws.security.javaeesec.cdi.extensions.HttpAuthenticationMechanismsTracker.getAuthMechs(HttpAuthenticationMechanismsTracker.java:186)
    ...

    The issue has been resolved and the web application now starts without the CWWKZ0002E error caused by the NPE.

  • MDB class Java heap leak on application stop

    There is a reference from the Liberty message-driven bean (MDB) code to the application’s MDB class through a pool that does not appear to be cleaned on application stop. See the following reference chain:

    '- enterpriseBeanClass com.ibm.ejs.container.MessageEndpointFactoryImpl @ 0x8d630f50
       '- ivMessageEnpointHandlerFactory com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandlerPool @ 0x8d6307c8
          '- discardStrategy com.ibm.ws.ejbcontainer.util.PoolImplThreadSafe @ 0x8d6301e0
             '- [3] java.lang.Object[10] @ 0x8677de20
                '- elementData java.util.ArrayList @ 0x817b8f10
                   '- pools com.ibm.ws.ejbcontainer.util.PoolManagerImpl @ 0x817b8ee8
                      '- poolManager com.ibm.ejs.container.EJSContainer @ 0x80f024e0

    This issue is now resolved and all references to applications classes are released when an application is stopped.

  • Datasource changes are not propagating to JPA during dynamic config update

    When updating the <datasource> properties (databaseName, password, portNumber, serverName, etc.) in the server.xml file while the server is running, the changes are not reflected in JPA applications.

    During server start, JPA Container does a JNDI lookup for the DataSource and provides that DataSource to the JPA provider, EclipseLink. After the configuration update fires, EclipseLink continues using the same DataSource that JPA Container provided. The DataSourceService isn’t closing the ConnectionFactory, so everything continues to work. For JPA, the application needs to be restarted in order for this to work, however the DataSourceService is not refreshing the application.

    This issue has been resolved and JPA applications are now dynamically updated when changes to the configuration occur.

New and updated guides since the previous release

As Open Liberty features and functionality continue to grow, we continue to add new guides to openliberty.io on those topics to make their adoption as easy as possible. Existing guides also receive updates in order to address any reported bugs/issues, keep their content current, and expand what their topic covers.

Get Open Liberty 22.0.0.12 now