Memory Safety in Backend Systems: Corruption, Leaks, Races, OOMs, and Safer Language Boundaries
Memory problems in backend systems fall into several different categories, and mixing them together makes debugging and security work harder.
A service can be memory-safe and still leak memory until the container is killed. A garbage-collected service can still have a data race. A Rust program can lose safety guarantees inside an unsafe block or foreign-function boundary. A C/C++ service can run for years and then hit one rare use-after-free under concurrency.
The first useful distinction is:
memory corruption/safety
memory retention/leaks
resource exhaustion/OOM
concurrency races
They overlap operationally, but they are not the same bug class.
What memory safety actually means
Memory safety is about preventing invalid access to memory.
Classic unsafe behaviors include:
- reading outside an allocated buffer
- writing outside an allocated buffer
- using memory after it has been freed
- freeing the same allocation twice
- dereferencing invalid/dangling pointers
- confusing incompatible memory representations
These bugs can cause:
- crashes
- silent data corruption
- information disclosure
- remote code execution in severe cases
NSA and CISA published joint guidance in 2025 encouraging adoption of memory-safe languages as a way to reduce this class of vulnerability in modern software.
Memory leak is not the same as memory corruption
A leak means memory remains reachable or allocated longer than useful.
Example:
request arrives
large object added to global cache
object never expires
repeat forever
The program may remain perfectly memory-safe while memory usage grows from:
200 MiB
500 MiB
2 GiB
8 GiB
until the operating system or container kills it.
This is primarily a resource-lifecycle/reliability bug rather than an out-of-bounds memory access.
You need different tools to diagnose it.
OOM can happen without a leak
A process can run out of memory even when every allocation is eventually released.
Examples:
- reading a 10 GiB upload into RAM at once
- accepting too many concurrent requests
- buffering messages for slow clients
- running thousands of expensive queries simultaneously
- decompressing attacker-controlled data into huge buffers
- creating one enormous in-memory aggregation
If peak live memory exceeds the process/container limit, “eventually freed” is irrelevant.
Memory architecture must consider peak concurrency and peak working set, not only leaks.
Data races are another separate class
A data race occurs when concurrent execution accesses shared memory unsafely, typically when at least one access writes.
A race can cause:
- lost updates
- corrupted structures
- inconsistent state
- crashes
- security failures
Some languages prevent many memory-corruption classes while still allowing race bugs through incorrect synchronization or shared-state design.
Go's official race-detector documentation explicitly notes that data races are a common and difficult concurrency bug class and provides go test -race / go run -race / go build -race to detect executed race conditions dynamically.
Why memory-safe languages matter
Languages can eliminate large categories of invalid-memory behavior through combinations of:
- bounds checks
- automatic memory management
- ownership/lifetime checking
- restricted pointer operations
- runtime type safety
Common examples of memory-safe-by-default ecosystems include languages such as:
- Rust safe code
- Go ordinary safe code
- Java
- C#
- JavaScript/TypeScript runtimes
The exact guarantees differ.
“Memory-safe language” does not mean:
no bugs
no races
no leaks
no OOM
no unsafe native dependencies
It means the language/runtime makes important invalid-memory operations unavailable or checked in its normal safe programming model.
Rust moves many checks to compile time
Rust's ownership and borrowing model is designed so ordinary safe Rust cannot perform several classes of invalid pointer/lifetime operation.
The compiler tracks rules around:
- ownership
- moves
- borrowing
- mutable aliasing
- lifetimes
This can prevent use-after-free and many iterator/pointer invalidation patterns before the program runs.
The trade-off is that developers must express ownership relationships clearly enough for the compiler to verify them.
That up-front constraint can be valuable in long-lived systems code where rare corruption bugs are extremely expensive.
unsafe Rust is a deliberate trust boundary
Rust still supports low-level operations through unsafe.
The Rust Reference documents unsafe operations such as:
- dereferencing raw pointers
- calling unsafe functions
- accessing union fields in unsafe ways
- interacting with unsafe extern declarations
unsafe does not disable every compiler check. It permits a specific set of operations whose correctness the compiler cannot prove.
A useful engineering rule is:
keep unsafe code small
encapsulate it behind safe APIs
write down its invariants
test it aggressively
Treat every unsafe block as security-sensitive code review surface.
FFI can reintroduce memory-unsafety into a safe language
A memory-safe service may call C/C++ through a foreign-function interface for:
- database drivers
- compression
- image/video codecs
- cryptography
- OS libraries
- high-performance native extensions
The safe language cannot automatically guarantee that native code obeys its memory rules.
Questions to review at an FFI boundary include:
- who owns the buffer?
- who frees it?
- can the native library retain the pointer after return?
- is the length correct?
- can callbacks outlive the original object?
- is concurrent use allowed?
A tiny wrapper around a native library can become the most security-sensitive part of an otherwise memory-safe backend.
Go is memory-safe by default, with explicit escape hatches
Normal Go code includes important protections such as bounds checking and garbage collection.
For example, accessing outside an array/slice boundary causes a runtime panic rather than silently reading arbitrary adjacent memory.
Go also deliberately exposes the unsafe package for low-level programming.
The Go specification warns that code using unsafe must be manually vetted for type safety and may not be portable.
That makes unsafe a review boundary similar in spirit to other low-level escape hatches.
cgo/native code needs separate scrutiny
When Go calls C through cgo, the program now spans two memory-management systems.
Native code can have its own:
- leaks
- invalid pointers
- buffer overflows
- thread-safety rules
Go runtime memory metrics also do not necessarily account for every byte allocated by C or directly memory-mapped outside the runtime.
If a Go process's RSS is much larger than the Go heap profile, inspect native/OS allocations rather than assuming the profiler is wrong.
Garbage collection solves reclamation, not object lifetime design
GC-based languages free developers from manually calling free for normal managed objects.
They do not know whether an object is logically useful.
If a global map still references one million expired sessions, the garbage collector correctly keeps them alive.
Common retention mistakes include:
- unbounded caches
- forgotten listeners/subscriptions
- goroutine/task closures retaining large objects
- maps keyed by user/request IDs with no cleanup
- queued messages that never drain
- metrics labels creating unbounded cardinality/state
A “leak” in a GC service often means the application accidentally kept references alive.
Unbounded queues are memory leaks with traffic attached
Consider:
producer: 10,000 messages/sec
consumer: 5,000 messages/sec
If the queue is unbounded, backlog grows forever.
The system needs one or more of:
- bounded queue size
- backpressure
- rate limiting
- load shedding
- scaling consumers
- dropping/coalescing disposable work
Queues, WebSocket buffers, background jobs, and logging pipelines all need explicit bounds.
“No leak in the code” does not help if the architecture intentionally stores an infinite backlog in RAM.
Limit request bodies before reading them fully
Never trust client payload size.
Dangerous patterns include:
read entire upload into byte array
parse unlimited JSON into memory
accept huge decompressed request
Enforce limits before expensive allocation:
- maximum HTTP body size
- upload size
- JSON nesting/array limits where needed
- decompression ratio / expanded-size limits
- gRPC message size
- WebSocket frame/message size
Resource limits are part of security because attackers can intentionally target memory exhaustion.
Stream large data instead of buffering everything
For large files and exports, prefer streaming/chunking when the operation supports it.
Conceptually:
input chunk
process chunk
write/output chunk
release reusable buffer
instead of:
load full input
build full transformed output
hold both simultaneously
Streaming lowers peak live memory and makes backpressure easier.
It can also complicate rollback/error behavior, so design the protocol deliberately.
Container limits change failure behavior
Modern backend services often run under cgroup/container memory limits.
A process may be healthy relative to host RAM and still be killed because it exceeded its container limit.
Monitor both:
- language/runtime heap
- process RSS / working set
- container/cgroup memory
They are different measurements.
Native allocations, file mappings, stacks, runtime metadata, and buffers can make RSS exceed the managed heap substantially.
Leave headroom below the hard limit
If a container limit is 1 GiB, do not design normal steady-state process memory to sit at 990 MiB.
Headroom is needed for:
- traffic bursts
- garbage-collection cycles
- temporary serialization buffers
- TLS/network buffers
- goroutine/thread stacks
- native allocations
- diagnostic/profiling work
A service that survives only under perfect steady-state allocation is already close to an outage.
Go provides a soft runtime memory limit
Modern Go exposes a soft memory limit through GOMEMLIMIT / runtime/debug.SetMemoryLimit.
The Go runtime uses this target to adjust garbage-collection behavior for memory it manages.
It is useful for containerized services, but it is not a magic hard cap over every byte the process can allocate.
The Go documentation notes that memory outside runtime-managed categories, such as some C allocations and mmap usage, is not part of the same accounting.
Set the runtime limit with headroom below the container limit and measure real RSS under production-like load.
A too-low memory limit can destroy performance
If the runtime memory target is unrealistically low, the garbage collector can run nearly continuously.
That can produce:
low apparent heap target
high CPU
poor throughput
high latency
Memory limits must be paired with capacity testing.
A process that stays under its memory cap by spending all CPU on GC is not healthy.
Use heap profiles to find retention
When a process grows unexpectedly, inspect allocation and live-object profiles.
Ask:
- which types consume the most live bytes?
- which allocation call sites dominate?
- is the growth in count or object size?
- does memory drop after GC?
- which references keep objects alive?
Take profiles at multiple points during growth rather than looking only after OOM.
A before/after comparison can reveal which object families continuously accumulate.
Measure RSS as well as heap
Heap usage may be stable while process RSS grows because of:
- native libraries
- memory-mapped files
- thread stacks
- allocator fragmentation
- runtime arenas not immediately returned to OS
- network/TLS buffers
Do not debug every memory incident solely through the managed heap graph.
Compare:
runtime heap
process RSS
container memory
native allocator metrics if available
The gap itself is diagnostic evidence.
Use race detectors under realistic workloads
Go's race detector finds races only in code paths that actually execute.
Run:
go test -race ./...
and consider exercising race-enabled builds under representative integration/load tests where practical.
A test suite with poor concurrency coverage cannot reveal races in code it never runs.
Race-detector builds have meaningful CPU/memory overhead and are normally test/debug tooling rather than the production binary.
Use AddressSanitizer for C/C++ and unsafe native boundaries
Clang's AddressSanitizer detects important bug classes including:
- heap/stack/global out-of-bounds access
- use-after-free
- use-after-return
- use-after-scope
- double-free
- invalid free
A typical test build uses:
clang++ -O1 -g -fsanitize=address -fno-omit-frame-pointer ...
ASan is a debugging/testing runtime and should not normally be linked into production security-sensitive binaries.
Use it continuously in CI/integration tests for memory-unsafe components rather than waiting for a production crash dump.
Add UndefinedBehaviorSanitizer where appropriate
C/C++ undefined behavior extends beyond invalid memory access.
Compiler sanitizers can catch classes such as invalid shifts, signed overflow depending on configuration, misalignment, and other undefined operations.
Combine tools according to the language/runtime and workload.
A sanitizer passing once does not prove absence of bugs; it proves the tested execution did not trigger a detected violation.
Fuzz parsers and protocol boundaries
Backend code most exposed to malformed input includes:
- HTTP parsers
- binary protocols
- image/file decoders
- compression formats
- custom serialization
- authentication token parsing
- native FFI wrappers
Fuzzing explores input combinations developers did not think to write as unit tests.
It is especially valuable for unsafe parsers because memory corruption often hides behind rare malformed input sequences.
Use coverage-guided fuzzing together with sanitizers where the toolchain supports it.
Limit recursion and nesting
Memory exhaustion can come from deeply nested valid-ish input:
JSON objects nested thousands of levels
recursive expression trees
archive nesting
GraphQL-like deep structures
Even memory-safe languages can exhaust stacks or heaps processing extreme nesting.
Set depth/complexity limits at untrusted parsing boundaries.
Do not rely only on total byte size.
Prefer bounded caches
A cache must have a capacity policy.
Possible bounds include:
- maximum entry count
- maximum total bytes
- per-entry size limit
- TTL
- LRU/LFU eviction
Also define what happens when the cache is full.
An unbounded in-process “cache” is just deferred OOM.
Cache keys themselves can become a memory problem when user-controlled cardinality grows without limit.
Watch goroutine/thread/task growth
Memory growth may come from execution units rather than heap objects alone.
Track:
- goroutine count
- thread count
- async task count
- worker queue length
A leaked goroutine can retain:
- stack memory
- request context
- buffers
- channel references
- database/network resources
If task count grows with traffic and never falls, investigate lifecycle/cancellation before tuning the garbage collector.
Cancellation is a memory feature too
When a client disconnects or deadline expires, downstream work should stop when safe.
Otherwise abandoned requests can keep:
- buffers
- queries
- response objects
- goroutines/tasks
- queued messages
alive long after the result is useful.
Propagate cancellation through database, RPC, and worker APIs that support it.
This improves both resource use and tail latency during overload.
Avoid large per-request allocations
One endpoint that allocates 50 MiB per request can be fine at concurrency 1 and catastrophic at concurrency 200.
Estimate peak live memory:
per-request working set
× concurrent requests
+ steady process memory
+ runtime/network/native headroom
Profile allocations under realistic concurrency rather than microbenchmarking one request in isolation.
Reducing transient allocation can lower GC pressure even when there is no leak.
Pooling can help or hurt
Buffer/object pools can reduce repeated allocations in high-throughput systems.
They can also keep huge buffers alive indefinitely.
If a request temporarily expands a pooled buffer to 64 MiB and that buffer returns to a long-lived pool, one rare request can permanently raise process memory.
Apply maximum retained capacities or discard oversized buffers rather than pooling everything.
Profile before introducing manual pooling; modern runtimes are often better at small allocations than intuition suggests.
Dependency choice is part of memory safety
A safe-language application can still depend on:
- native codecs
- database client libraries with C components
- unsafe cryptography
- OS bindings
Maintain an inventory of native/unsafe dependencies and patch them promptly.
Where possible, prefer pure memory-safe implementations for high-risk parsers and network-facing components.
When replacing a mature native dependency, benchmark correctness and security as well as speed.
Production memory telemetry
Track at least:
- process RSS / working set
- container memory usage and limit
- managed heap live/allocated bytes
- GC frequency and pause/CPU cost
- allocation rate
- goroutine/thread/task count
- queue/buffer depth
- OOM kills/restarts
- native memory where observable
Alert on trend and headroom, not only “memory reached 99%.”
A service whose memory climbs 50 MiB every hour has a problem long before the limit alarm fires.
Incident triage checklist
When memory grows unexpectedly:
- Compare heap vs RSS vs container usage.
- Check request/concurrency and queue depth.
- Check goroutine/thread/task count.
- Force/observe GC behavior in a safe diagnostic environment.
- Capture heap/allocation profiles.
- Inspect native allocations/FFI if RSS exceeds managed heap substantially.
- Look for recently introduced caches/batching/buffers.
- Reproduce under load with race/sanitizer tools where applicable.
- Verify memory actually returns after traffic drops.
- Fix lifecycle/architecture before simply increasing the limit.
More RAM can delay an OOM without fixing the cause.
A practical engineering strategy
For new backend components:
- prefer memory-safe languages when they meet requirements
- isolate unsafe/native code behind small reviewed boundaries
- bound every request, queue, cache, and stream
- propagate cancellation
- profile realistic concurrency
- use race detectors/sanitizers/fuzzing in CI
- monitor both runtime heap and process/container memory
For existing C/C++ systems that cannot be rewritten immediately:
- prioritize externally exposed parsers and high-risk components
- add ASan/UBSan and fuzzing to test pipelines
- modernize ownership APIs
- reduce unsafe pointer arithmetic
- migrate components incrementally when practical
Memory safety improvement does not require one giant rewrite to begin reducing risk.
Production checklist
Before calling a backend memory-resilient, verify:
- language/runtime safety guarantees are understood
unsafe, native, and FFI boundaries are inventoried- body/message/upload sizes have hard limits
- queues and caches are bounded
- large data is streamed where appropriate
- concurrency has explicit limits/backpressure
- cancellation releases abandoned work
- memory limit leaves headroom below the container cap
- heap and RSS are both monitored
- task/goroutine/thread counts are monitored
- race detector runs against meaningful concurrency paths
- unsafe/native components run under sanitizers in CI
- parsers/high-risk inputs are fuzzed where practical
- OOM behavior and restart/recovery are tested
Memory safety is not one switch. A secure backend combines memory-safe language guarantees, small unsafe boundaries, bounded resource usage, concurrency discipline, and tooling that catches violations before production.
References
Discussion (0)