CWE-826 is a product releasing a resource that it, or another actor, still intends to use. Memory, file descriptors, locks, handles and connections are all candidates.
MITRE marks it as not language specific. It is closely related to CWE-825, but the failure is different: there, the release was fine and a stale pointer remained. Here, the release should not have happened at all.
How it happens
Ownership gets muddled. One component decides it is finished and closes something another component is still holding. The freed resource may be reused in the meantime.
MITRE's observed example is CVE-2009-3547, a chain where a race condition might allow a resource to be released before it is operated on, leading to a NULL dereference.
// Vulnerable: callback closes the fd the caller still uses
void on_done(int fd) { close(fd); }
void run(int fd) {
start_async(fd, on_done);
write(fd, "x", 1); // may run after close, fd may be reused
}
What an attacker gains
MITRE lists reading data that now belongs to a different user or entity if the released resource is reused, crashes when the resource is no longer in the expected state, and modification of data or memory, which can extend to code execution.
How to find it
MITRE names automated static analysis. Add review of lifetimes: for every resource, write down who releases it and what else might still hold it. Stress testing with concurrency helps expose release before use.
How to fix it
The record has no formal mitigations. Practical steps:
- Define one owner per resource.
- Use reference counting or scoped ownership so release happens only when the last user is done.
- Synchronize release with use when multiple threads share the resource.
- Clear references after release.
Quick check
Why can a premature close leak another user's data?
Once released, the identifier can be reused for a different purpose. A later access through the old reference may then touch someone else's resource.
