IBM Support

PI96383: High CPU and increased AUX storage in WebSphere Daemon if connection is closed during SSL handshake

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • This issue affects only WAS Daemon address space using SSL.
    If a connection is closed during SSL handshake, it's possible
    WebSphere daemon may incorrectly be checking return code from
    unix recv() call and not realize the connection is being closed.
    This may result in a "loop" like behavior with high CPU usage.
    If hardware-crypto is used, the symptoms may be rapidly
    increasing aux storage usage.
    
    A thread doing a handshake may look like this:
    
    crypto_rsa_private_decrypt
                +0000143A              GSKC64
    read_v3_client_key_exchange
                +0000056C              GSKS64
    process_v3_server_handshake
                +000003C0              GSKS64
    gsk_perform_v3_server_handshake
                +00000668              GSKS64
    gsk_secure_socket_init
                +00000E24              GSKS64
    gsk_secure_socket_init
                +00000038              GSKSSL64
    DaemonSSSLManager::processSSLHandshake(SSLConfig*)
    CF_TCP_Connection::init_As_postAccept(CF_TCP_AsynchData*,aio
    CF_TCP_Connection_Object_Manager::processAsyncANRComplete(ac
    ACR_ExecutionThread::processTcpAsyncANRComplete(acrwObj*)
    ACR_ExecutionThread::RemoveAndProcessWork(ThreadCleanUp*)
    
    Or this:
    MULT_WORD_ULONG_BN
                +00000082              GSKC64
    crypto_monty_square
                +000001EA              GSKC64
    crypto_monty_modexp
                +000004F8              GSKC64
    crypto_monty_crtexp
                +000001EC              GSKC64
    crypto_rsa_private_decrypt
                +00001A86              GSKC64
    read_v3_client_key_exchange
                +0000056C              GSKS64
    process_v3_server_handshake
                +000003C0              GSKS64
    gsk_perform_v3_server_handshake
                +00000668              GSKS64
    gsk_secure_socket_init
                +00000E24              GSKS64
    gsk_secure_socket_init
                +00000038              GSKSSL64
    DaemonSSSLManager::processSSLHandshake(SSLConfig*)
    CF_TCP_Connection::init_As_postAccept(CF_TCP_AsynchData*,aio
    CF_TCP_Connection_Object_Manager::processAsyncANRComplete(ac
    ACR_ExecutionThread::processTcpAsyncANRComplete(acrwObj*)
    
    Systrace shows the following repeating calls:
    
    DSP        00000000_0161BDE8  00000000 00029474 0894A070  000000
    00000000 0025 0058 07:32:56.419941201 00DA
               07040400 80000000
    PR     ...   0            00_2034C81A 20F57FD6
    0058
    PC     ...   2            00_014963D8     01319        send/recv
    PR     ...   0            00_014963D8       00_20F55280
    0058
    PC     ...   2            00_014963D8     01319        send/recv
    PR     ...   0            00_014963D8       00_20F55280
    0058
    PC     ...   2            00_2034C81A     02F00
    PC     ...   0      01618562              0030A        LocAscb
    PR     ...   0      01618562 01625AAA
    0025
    PC     ...   0      20FDD10A              0030E        Post
    SSRV   12B          00000000  7F68E014 00000000 00000000  Post
    07:32:56.419976927 00DA
                                  00000000
    PR     ...   0      20FDD10A 0159AA04
    0025
    SSRV   11E          A0FDD14C  08BD43F0 00000000 00000000  Pause
    07:32:56.419977633 00DA
                                  00000000
    

Local fix

  • n/a
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server V8.5                                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: High CPU or increased storage           *
    *                      consumption after attempting an SSL     *
    *                      connection to the daemon process.       *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    If an SSL connection to the daemon process is closed while
    performing the SSL handshake, the daemon process may enter a
    loop which can cause a permanent increase in real storage used
    by the daemon, or temporarily consume a large amount of CPU.
    The condition is most likely to occur when running security
    vulnerability scanning tools against the SSL port of the
    daemon process.
    

Problem conclusion

  • Code was added to clean up resources used by the SSL connection
    when the connection is closed during the SSL handshake.
    
    The fix for this APAR is currently targeted for inclusion in
    fix packs 8.5.5.14 and 9.0.0.8.  Please refer to the
    Recommended Updates page for delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI96383

  • Reported component name

    WEBSPHERE FOR Z

  • Reported component ID

    5655I3500

  • Reported release

    850

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-04-10

  • Closed date

    2018-05-18

  • Last modified date

    2018-05-18

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WEBSPHERE FOR Z

  • Fixed component ID

    5655I3500

Applicable component levels

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"850","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
19 October 2021