Safeguard
Application Security•

ASVS 5.0 V1.4.3: Release Memory and Clear Dangling Pointers

ASVS 5.0 V1.4.3 (Level 2) asks you to free allocated resources and null out references so use after free bugs cannot happen. How to build and test it.

Safeguard Security Team
3 min read

ASVS 5.0 V1.4.3 requires that dynamically allocated memory and resources are released, and that references to freed memory are removed or set to null. The goal is to prevent dangling pointers and use after free bugs. It is Level 2.

Why it matters

A use after free lets an attacker who controls what gets allocated into the freed slot change the behaviour of code that still holds the old pointer. This is a common route to code execution in browsers, parsers and network daemons written in C and C++. Leaked resources are a milder cousin: file handles and connections that are never released become a denial of service.

How to implement it

Prefer ownership models that make the mistake hard. Use smart pointers in C++, ownership in Rust, and scoped cleanup elsewhere: defer in Go, try with resources in Java, using in C#, context managers in Python.

When you must use raw pointers, free once and clear the pointer:

free(buf);
buf = NULL;

Do not copy a pointer into several places without a clear owner, and keep the free path in one function so reviews can see it.

How to test it

Build and run your tests with AddressSanitizer (-fsanitize=address), which reports use after free and double free with a stack trace. Run native components under Valgrind in CI as well, and add a fuzzer so error paths, where cleanup bugs live, actually run.

Language notes

In C++, std::unique_ptr and std::shared_ptr free memory when the owner goes out of scope, so a raw delete is rare. Rust rejects most dangling references at compile time. In garbage collected languages, memory is not the problem, but handles, sockets and locks still need explicit release, and a missed close can exhaust a connection pool.

Review native extensions and parsers more closely than the rest. They are written in C or C++ even in Python, Node and Java applications, and they handle untrusted input.

Common mistakes

  • Freeing on the success path but not on early error returns.
  • Nulling one copy of a pointer while another copy stays live.
  • Skipping sanitizers because the build is slower.

Quick check

Does setting a pointer to null after free fix every use after free?

No. It only clears that one variable. Other copies of the pointer remain dangling, so you also need clear ownership.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.