CVE-2024-1394: Golang RSA Memory Leak DoS Vulnerability

CVE-2024-1394 Overview

A memory leak vulnerability was discovered in the Golang FIPS OpenSSL RSA encrypting/decrypting code that can lead to resource exhaustion when processing attacker-controlled inputs. The flaw exists in github.com/golang-fips/openssl/openssl/rsa.go#L113 where pkey and ctx objects are leaked due to improper handling of named return parameters in error cases. When errors occur during context initialization or property setting, the function returns nil values that prevent the deferred cleanup function from properly freeing the allocated resources.

Critical Impact

This vulnerability enables attackers to exhaust system memory resources through repeated RSA encryption/decryption operations, potentially causing denial of service conditions in applications using the affected Golang FIPS OpenSSL library.

Affected Products

• github.com/golang-fips/openssl (prior to patched versions)
• github.com/microsoft/go-crypto-openssl (prior to patched versions)
• Red Hat Enterprise Linux products using affected Go toolsets

Discovery Timeline

• 2024-03-21 - CVE-2024-1394 published to NVD
• 2025-05-13 - Last updated in NVD database

Technical Details for CVE-2024-1394

Vulnerability Analysis

The vulnerability is classified as CWE-401 (Missing Release of Memory after Effective Lifetime), a common memory management flaw that occurs when allocated memory is not properly freed. In this case, the affected function uses Go's named return parameters pattern to handle resource cleanup via deferred functions. However, when error conditions are encountered during RSA key context initialization, the code follows a return nil, nil, fail(...) pattern that sets both pkey and ctx to nil before the deferred cleanup function executes. Since the deferred function checks for non-nil values before freeing resources, the memory allocated for these objects is never released.

This type of memory leak is particularly dangerous in cryptographic code because RSA operations are often performed repeatedly at scale—during TLS handshakes, API authentication, or data encryption workflows. An attacker can exploit this by submitting malformed or specially crafted inputs that trigger the error paths, causing memory to accumulate with each failed operation until the system runs out of available resources.

Root Cause

The root cause lies in the misuse of Go's named return parameters combined with deferred cleanup functions. The original code declared ctx as a named return parameter in the function signature (func newCipherCtx(...) (ctx C.GO_EVP_CIPHER_CTX_PTR, err error)). When an error occurred, the code would return nil for the context, which overwrote the named parameter. The deferred cleanup function then saw a nil value and skipped the memory deallocation. The same pattern affected the setupEVP function where ctx was declared as a named return but could be set to a non-nil value before an error occurred on a different code path.

Attack Vector

An attacker can exploit this vulnerability remotely by sending specially crafted RSA encryption or decryption requests to applications using the vulnerable library. The attack requires no authentication or user interaction. By repeatedly triggering error conditions in the RSA processing code—through malformed keys, invalid padding, or other cryptographic parameter errors—an attacker can force the application to allocate memory that is never freed. Over time, this memory exhaustion leads to denial of service as the application consumes all available system memory and either crashes or becomes unresponsive.

// Security patch in cipher.go - Changed named return to anonymous return
// Source: https://github.com/golang-fips/openssl/commit/85d31d0d257ce842c8a1e63c4d230ae850348136

// BEFORE (vulnerable):
func newCipherCtx(kind cipherKind, mode cipherMode, encrypt cipherOp, key, iv []byte) (ctx C.GO_EVP_CIPHER_CTX_PTR, err error) {
	// ctx was a named return parameter that could be overwritten

// AFTER (patched):
func newCipherCtx(kind cipherKind, mode cipherMode, encrypt cipherOp, key, iv []byte) (_ C.GO_EVP_CIPHER_CTX_PTR, err error) {
	ctx := C.go_openssl_EVP_CIPHER_CTX_new()
	if ctx == nil {
		return nil, fail("unable to create EVP cipher ctx")
	}
	// ctx is now a local variable, properly scoped for deferred cleanup

// Security patch in evp.go - Fixed memory leak in setupEVP
// Source: https://github.com/microsoft/go-crypto-openssl/commit/104fe7f6912788d2ad44602f77a0a0a62f1f259f

func setupEVP(withKey withKeyFunc, padding C.int,
	h, mgfHash hash.Hash, label []byte, saltLen C.int, ch crypto.Hash,
	init initFunc) (_ C.GO_EVP_PKEY_CTX_PTR, err error) {
	var ctx C.GO_EVP_PKEY_CTX_PTR
	withKey(func(pkey C.GO_EVP_PKEY_PTR) C.int {
		ctx = C.go_openssl_EVP_PKEY_CTX_new(pkey, nil)
		return 1
	})
	if ctx == nil {
		return nil, newOpenSSLError("EVP_PKEY_CTX_new failed")
	}
	defer func() {
		if err != nil {
			if ctx != nil {
				// Now ctx is properly available for cleanup
			}
		}
	}()

Detection Methods for CVE-2024-1394

Indicators of Compromise

• Unusual memory growth in Go applications performing RSA operations
• Gradual increase in process memory consumption without corresponding workload increase
• Application crashes or OOM (Out of Memory) killer events in system logs
• High volume of failed RSA encryption/decryption operations in application logs

Detection Strategies

• Monitor memory utilization trends for Go applications using FIPS-compliant cryptographic libraries
• Implement application-level memory profiling using Go's runtime/pprof to identify memory leaks
• Track RSA operation error rates and correlate with memory consumption patterns
• Use container memory limits to detect and alert on abnormal memory growth before system-wide impact

Monitoring Recommendations

• Configure alerts for processes exceeding expected memory thresholds
• Implement regular memory profiling in staging environments with production-like workloads
• Review application logs for patterns of repeated cryptographic operation failures
• Monitor Go runtime metrics including heap allocation and garbage collection statistics

How to Mitigate CVE-2024-1394

Immediate Actions Required

• Update github.com/golang-fips/openssl to the patched version containing commit 85d31d0d257ce842c8a1e63c4d230ae850348136
• Update github.com/microsoft/go-crypto-openssl to the patched version containing commit 104fe7f6912788d2ad44602f77a0a0a62f1f259f
• Apply relevant Red Hat security advisories for affected enterprise products
• Rebuild Go applications that depend on the vulnerable library versions

Patch Information

The vulnerability has been addressed through patches in both the golang-fips/openssl and microsoft/go-crypto-openssl repositories. The fix changes named return parameters to anonymous returns (using _), ensuring that local variables are properly scoped for deferred cleanup functions. Red Hat has released multiple security advisories addressing this vulnerability across their product portfolio, including RHSA-2024:1462, RHSA-2024:1468, and numerous others. Full details are available in the GitHub Security Advisory GHSA-78hx-gp6g-7mj6 and Go Vulnerability Advisory GO-2024-2660.

Workarounds

• Implement application-level memory limits and automatic restart mechanisms to reduce impact of memory exhaustion
• Deploy rate limiting on endpoints that trigger RSA operations to slow potential exploitation
• Consider switching to non-FIPS Go crypto implementations temporarily if FIPS compliance is not strictly required
• Monitor and alert on memory consumption to enable early detection and manual intervention

# Verify your Go module dependencies for vulnerable versions
go list -m all | grep -E "golang-fips/openssl|go-crypto-openssl"

# Update to patched versions
go get github.com/golang-fips/openssl@latest
go get github.com/microsoft/go-crypto-openssl@latest

# Rebuild your application
go build -o myapp ./...