We are investigating an escalation with a customer where the Aerospike Server container (asd) intermittently reaches 100% CPU utilization.
Performance profiling shows that OpenSSL's libcrypto (version from openssl-libs-1.1.1k-12.el8_9.x86_64) consumes >90% CPU during these events.

Aerospike's internal analysis indicates that this behavior is similar to the conditions described in CVE‑2022‑0778, which involves an infinite loop in BN_mod_sqrt() during certificate/EC parameter parsing.
NVD states this vulnerability affects OpenSSL 1.1.1 prior to 1.1.1n and can result in a DoS‑like infinite loop during EC parameter parsing.
[rpmfind.net]

We understand that RHEL 8 uses a backported OpenSSL 1.1.1k stream, and fixes for CVE‑2022‑0778 should already be included in the RHEL builds (including the 1.1.1k‑X packages). Snyk confirms that the RHEL‑fixed version for this CVE is 1:1.1.1k‑6.el8_5 and higher, and our environment is running 1.1.1k‑12.el8_9.

[openssl-library.org] [support.ch...kpoint.com]

However, profiling indicates that libcrypto may be entering a tight loop / heavy CPU condition that resembles this vulnerability's behavior. We are seeking Red Hat's assistance to confirm:

Request for Red Hat Support:

1. Verification of Backport

a) Please confirm whether CVE‑2022‑0778 is fully backported into:

{{openssl-libs-1.1.1k-12.el8_9.x86_64
openssl-1.1.1k-12.el8_9.x86_64}}

b) Please confirm whether openssl-1.1.1k contains all the fixes present in openssl-1.1.1n ?

2. Known Issues / Regressions

Are there any known performance regressions or corner‑case loops involving the following in the RHEL8 OpenSSL backport?

• EC parameter parsing
• ASN.1 certificate handling
• TLS handshake cert validation
• X509 parsing of malformed or unexpected input

3. Updated Builds

Should we upgrade to a newer OpenSSL build, such as the RHEL 8.10 version (1.1.1k‑14.el8_10) to address this issue?

Red Hat Advisory RHSA‑2024:7848 indicates ongoing OpenSSL maintenance in RHEL 8.
[access.redhat.com]

4. Request for Root Cause Guidance

If possible, please advise on:

• Whether Aerospike's TLS usage could trigger pathological behavior despite the backport
• Whether additional backports or patches are planned
• Whether you recommend enabling additional OpenSSL debugging logs or ciphersuite restrictions to mitigate CPU runaway conditions

Environment Details:

• Platform: Kubernetes (containerized Aerospike deployment)
• Base OS: RHEL 8.9 container / UBI8 8.9
• OpenSSL packages:
  {{openssl-libs-1.1.1k-12.el8_9.x86_64
  openssl-1.1.1k-12.el8_9.x86_64}}
• Service impacted: Aerospike Server (asd process)
• Issue: Occasional CPU spikes to 100%
• Observed behavior: libcrypto.so dominates >90% CPU (perf attached)
• TLS: Enabled (client certs)