GPU VulnDB

Database/Kernel, userspace & hypervisor

libssh: unchecked OpenSSL error can leave a partially initialized ChaCha20 context in use

CVE-2025-5987Kernel, userspace & hypervisorcurated

Impact

When libssh sets up the ChaCha20 cipher through OpenSSL, an allocation failure returns an OpenSSL error code that aliases SSH_OK, so libssh does not notice the failure and continues with a partially initialized cipher context. Red Hat describes the result as undefined behavior, including compromised confidentiality and integrity of the session or a crash. Reaching it requires the attacker to exhaust heap space first, which is why the record scores attack complexity as high - this is not a drive-by. It matters on a fleet because libssh sits under management and orchestration paths rather than interactive logins: libvirt's SSH transport, automation tooling, and anything in the Red Hat and OpenShift stack that links it. A session whose integrity silently degrades on a control path is worse than one that fails closed.

Who can reach it

A network peer of a libssh-based SSH client or server who can also drive the process to heap exhaustion. No authentication is required per the vector, but the memory-pressure precondition makes this hard to trigger deliberately.

What to do

Red Hat has shipped errata for RHEL 9, RHEL 10 and OpenShift Container Platform 4.13 - apply the libssh package update from the RHSA matching your release. Anything already running against the old shared library keeps using it, so restart the services that link libssh (libvirtd and management or automation daemons) after the update. No node drain or reboot is implied by the record.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.