oven-sh/bun · critical · CertError

OUT_OF_MEM

OUT_OF_MEM

Error message

OUT_OF_MEM

What it means

X509 verify result 17 (X509_V_ERR_OUT_OF_MEM): BoringSSL/X.509 verification ran out of memory while building or verifying the chain. Mapped via get_cert_error_from_no (src/http/lib.rs:1536) to CertError::OUT_OF_MEM. Unlike the sibling variants, this is a resource failure, not a trust decision.

Source

Thrown at src/http/error.rs:155

    #[error("CRL_SIGNATURE_FAILURE")]
    CRL_SIGNATURE_FAILURE,
    #[error("CERT_NOT_YET_VALID")]
    CERT_NOT_YET_VALID,
    #[error("CERT_HAS_EXPIRED")]
    CERT_HAS_EXPIRED,
    #[error("CRL_NOT_YET_VALID")]
    CRL_NOT_YET_VALID,
    #[error("CRL_HAS_EXPIRED")]
    CRL_HAS_EXPIRED,
    #[error("ERROR_IN_CERT_NOT_BEFORE_FIELD")]
    ERROR_IN_CERT_NOT_BEFORE_FIELD,
    #[error("ERROR_IN_CERT_NOT_AFTER_FIELD")]
    ERROR_IN_CERT_NOT_AFTER_FIELD,
    #[error("ERROR_IN_CRL_LAST_UPDATE_FIELD")]
    ERROR_IN_CRL_LAST_UPDATE_FIELD,
    #[error("ERROR_IN_CRL_NEXT_UPDATE_FIELD")]
    ERROR_IN_CRL_NEXT_UPDATE_FIELD,
    #[error("OUT_OF_MEM")]
    OUT_OF_MEM,
    #[error("DEPTH_ZERO_SELF_SIGNED_CERT")]
    DEPTH_ZERO_SELF_SIGNED_CERT,
    #[error("SELF_SIGNED_CERT_IN_CHAIN")]
    SELF_SIGNED_CERT_IN_CHAIN,
    #[error("UNABLE_TO_GET_ISSUER_CERT_LOCALLY")]
    UNABLE_TO_GET_ISSUER_CERT_LOCALLY,
    #[error("UNABLE_TO_VERIFY_LEAF_SIGNATURE")]
    UNABLE_TO_VERIFY_LEAF_SIGNATURE,
    #[error("CERT_CHAIN_TOO_LONG")]
    CERT_CHAIN_TOO_LONG,
    #[error("CERT_REVOKED")]
    CERT_REVOKED,
    #[error("INVALID_CA")]
    INVALID_CA,
    #[error("PATH_LENGTH_EXCEEDED")]
    PATH_LENGTH_EXCEEDED,
    #[error("INVALID_PURPOSE")]

View on GitHub (pinned to 8c5296ac45)

Solutions

  1. Raise the container/process memory limit or free memory before retrying
  2. Profile for leaks — the TLS verification itself needs only a few KB
  3. If a specific server triggers it with an enormous chain, that server is broken or hostile; avoid/fix it
  4. Retry once after GC/memory relief — a transient OOM clears
Defensive patterns

Strategy: retry

Validate before calling

// guard headroom before starting TLS-heavy batches
function assertMemoryHeadroom(minFreeBytes = 64 * 1024 * 1024) {
  const { rss, systemMemory } = Bun.memoryUsage ? { ...Bun.memoryUsage, systemMemory: 0 } : { rss: 0, systemMemory: 0 };
  const pages = Bun.syscall ? null : null; // keep it simple: rely on cgroup/container limits externally
  if (rss > Number(process.env.MAX_RSS_BYTES ?? Infinity) - minFreeBytes) {
    throw new Error("Insufficient memory headroom for TLS workload");
  }
}

Type guard

function isCertErrorCode(e: unknown, code = "OUT_OF_MEM"): e is Error & { code: string } {
  return e instanceof Error && (e as any).code === code;
}

Try / catch

async function fetchWithMemRetry(url: string, tries = 2) {
  for (let i = 0; ; i++) {
    try {
      return await fetch(url);
    } catch (e) {
      if (i < tries && isCertErrorCode(e, "OUT_OF_MEM")) {
        Bun.gc(true); // free memory, then retry once
        continue;
      }
      throw e;
    }
  }
}

Prevention

When it happens

Trigger: TLS handshake on a process at its memory ceiling — very large chains (hundreds of intermediates, adversarial servers), or the process/container already near its RSS/cgroup limit when verification allocates.

Common situations: Containers with tight memory limits (cgroup OOM pressure), memory leaks elsewhere leaving no headroom, or malicious/broken servers presenting pathological chains.

Related errors


AI-assisted analysis of oven-sh/bun@8c5296ac45 (2026-08-16). Data as JSON: /api/errors/bb0977e52d320207. Report an issue: GitHub.