nodejs/node

crypto,quic: missing NULL checks for OpenSSL allocation functions

Open

#62774 opened on Apr 16, 2026

View on GitHub
 (7 comments) (0 reactions) (0 assignees)JavaScript (117,218 stars) (35,535 forks)batch import
cryptogood first issue

Description

Version

v22.13.1

Platform

A container based on Ubuntu 22.04 OS

Subsystem

crypto, quic

What steps will reproduce the bug?

This is a set of latent defects found by static analysis (Svace), not a runtime-reproducible bug. The issues are:

  1. src/crypto/crypto_aes.cc, function AES_Cipher (line 46): EVP_CIPHER_CTX_new() result used without NULL check. Cross-file statistics: checked in 37 of 40 call sites.

  2. src/crypto/crypto_aes.cc, function AES_CTR_Cipher2 (line 225): EVP_CIPHER_CTX_new() result used without NULL check. Same detector, same function.

  3. src/crypto/crypto_ec.cc, function ECKeyExportTraits::DoExport (line 1264): EC_KEY_new() result used without NULL check. Cross-file statistics: checked in 5 of 6 call sites.

  4. src/quic/tlscontext.cc, function TLSSession::Initialize (line 2051): SSL_new() result used without NULL check. Cross-file statistics: checked in 9 of 10 call sites.

  5. src/crypto/crypto_cipher.cc, function CipherBase::CommonInit (line 2570): EVP_CIPHER_CTX_new() result wrapped in unique_ptr and used without verifying it's non-null.

How often does it reproduce? Is there a required condition?

Would manifest under memory pressure when OpenSSL fails to allocate internal structures. Not trivially reproducible in normal operation.

What is the expected behavior? Why is that the expected behavior?

Allocation failures should result in a controlled error (thrown JavaScript exception or appropriate error status), not a NULL pointer dereference / segmentation fault.

What do you see instead?

Potential SIGSEGV on allocation failure.

Additional information

These findings come from the ISPRAS open-source static analysis working group. All issues are of the same class (OpenSSL allocation function return value used without NULL check) and can be fixed together.

Contributor guide

Tech stack
javascriptcpp
Domain
backendsecurity
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
C/C++ programmingNode.js core internalsOpenSSL API
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70
Research direction
Examine the files listed in the issue: src/crypto/crypto aes.cc, src/crypto/crypto ec.cc, src/quic/tlscontext.cc, and src/crypto/crypto cipher.cc. For each call to EVP CIPHER CTX new(), EC KEY new(), SSL new(), add a NULL check after the allocation. If NULL, return an appropriate error (e.g., throw a JavaScript exception or set an error status). The maintainers have provided cross file statistics indicating that similar checks exist elsewhere, so follow the existing patterns.