CWE-771 describes a product that does not properly maintain a reference to a resource it has allocated, which prevents the resource from being reclaimed. Think of a handle that was created, dropped on the floor, and can no longer be returned.
MITRE notes this does not necessarily apply in languages or frameworks that garbage collect, because removing all references can signal that a resource is ready for reclaiming. It matters most where cleanup is manual.
How it happens
A function allocates a resource, stores the only pointer in a local variable, and returns or overwrites it. The resource still exists, but nothing knows where it is. Repeat that in a loop and the pool shrinks with every pass.
What an attacker gains
The recorded consequence is availability. An attacker who can influence these allocations can deplete the available resource pool and stop other processes from getting the same type of resource.
How to find it
Static analysis can find some instances by tracing data flow from allocation to release. Run long soak tests as well, and watch resource counts such as memory, handles and connections. A count that only climbs points at a leak.
How to fix it
- Make one owner responsible for each resource and keep a reference until it is released.
- Apply the resource limits your operating system or environment offers. On POSIX, MITRE names setrlimit() and getrlimit() for this.
- Handle the failure case. Check for errors when resources become unavailable instead of assuming allocation always works.
Limits will not stop an attacker from hurting other users of the same service, but they protect the rest of the system.
Quick check
Does a garbage collected language remove this risk?
Mostly for memory, since dropped references allow reclaiming. Resources like sockets and files can still need explicit release.
