Particle.news

HollowByte Causes Persistent Memory Bloat in OpenSSL, Patch Available

Fixes that stop tiny attacker‑supplied length fields from ballooning server memory were released without a CVE.

Overview

  • Okta’s Red Team disclosed in mid‑July that an 11‑byte TLS input can make vulnerable OpenSSL servers allocate a large receive buffer by trusting the handshake’s three‑byte length field before any body bytes arrive.
  • On glibc‑based Linux systems freed buffers are kept for reuse instead of returned to the kernel, so varied claimed sizes across many short connections fragment the heap and leave resident memory permanently bloated until the process is restarted.
  • OpenSSL merged fixes that delay buffer growth until data actually arrives and published them in 4.0.1 and backports to 3.6.3, 3.5.7, 3.4.6, and 3.0.21, and operators should upgrade and restart affected services to reclaim memory.
  • The project treated the change as a bug or hardening fix rather than a tracked security advisory, so no CVE, changelog entry, or clear advisory exists and downstream packages may not make the fix discoverable; the DTLS path was not fixed.
  • Okta’s NGINX tests showed real impact with a 1 GB server OOM‑killed and a 16 GB server losing about 25% of memory, and standard connection limits may not block the attack so administrators should ask vendors or maintainers whether their OpenSSL builds include the patch.