Skip to end of metadata
Go to start of metadata

Sensitive data stored in reusable resources may be inadvertently leaked to a less privileged user or attacker if not properly cleared. Examples of reusable resources include

  • Dynamically allocated memory
  • Statically allocated memory
  • Automatically allocated (stack) memory
  • Memory caches
  • Disk
  • Disk caches

The manner in which sensitive information can be properly cleared varies depending on the resource type and platform.

Noncompliant Code Example (free())

Dynamic memory managers are not required to clear freed memory and generally do not because of the additional runtime overhead. Furthermore, dynamic memory managers are free to reallocate this same memory. As a result, it is possible to accidentally leak sensitive information if it is not cleared before calling a function that frees dynamic memory. Programmers also cannot rely on memory being cleared during allocation. (See void MEM09-C. Do not assume memory allocation functions initialize memory.)

To prevent information leakage, sensitive information must be cleared from dynamically allocated buffers before they are freed. Calling free() on a block of dynamic memory causes the space to be deallocated; that is, the memory block is made available for future allocation. However, the data stored in the block of memory to be recycled may be preserved. If this memory block contains sensitive information, that information may be unintentionally exposed.

In this example, sensitive information stored in the dynamically allocated memory referenced by secret is copied to the dynamically allocated buffer, new_secret, which is processed and eventually deallocated by a call to free(). Because the memory is not cleared, it may be reallocated to another section of the program where the information stored in new_secret may be unintentionally leaked.

Compliant Solution

To prevent information leakage, dynamic memory containing sensitive information should be sanitized before being freed. Sanitization is commonly accomplished by clearing the allocated space (that is, filling the space with '\0' characters).

The calloc() function ensures that the newly allocated memory has also been cleared. Because sizeof(char) is guaranteed to be 1, this solution does not need to check for a numeric overflow as a result of using calloc(). (See MEM07-C. Ensure that the arguments to calloc(), when multiplied, do not wrap.)

See MSC06-C. Beware of compiler optimizations for a definition and discussion of using the memset_s() function.

Noncompliant Code Example (realloc())

Reallocating memory using realloc() can have the same problem as freeing memory. The realloc() function deallocates the old object and returns a pointer to a new object. Using realloc() to resize dynamic memory may inadvertently expose sensitive information, or it may allow heap inspection, as described in Fortify Taxonomy: Software Security Errors [Fortify 2006] and NIST's Source Code Analysis Tool Functional Specification [Black 2007].

In this example, when realloc() is called, it may allocate a new, larger object, copy the contents of secret to this new object, free() the original object, and assign the newly allocated object to secret. However, the contents of the original object may remain in memory.

The secret_size is tested to ensure that the integer multiplication (secret_size * 2) does not result in an integer overflow. (See INT30-C. Ensure that unsigned integer operations do not wrap.)

Compliant Solution

A compliant program cannot rely on realloc() because it is not possible to clear the memory before the call. Instead, a custom function must be used that operates similarly to realloc() but sanitizes sensitive information as heap-based buffers are resized. Again, sanitization is done by overwriting the space to be deallocated with '\0' characters.

The calloc() function ensures that the newly allocated memory is also cleared. Because sizeof(char) is guaranteed to be 1, this solution does not need to check for a numeric overflow as a result of using calloc(). (See MEM07-C. Ensure that the arguments to calloc(), when multiplied, do not wrap.)

Risk Assessment

In practice, this type of security flaw can expose sensitive information to unintended parties. The Sun tarball vulnerability discussed in Secure Coding Principles & Practices: Designing and Implementing Secure Applications [Graf 2003] and Sun Security Bulletin #00122 [Sun 1993] shows a violation of this recommendation, leading to sensitive data being leaked. Attackers may also be able to leverage this defect to retrieve sensitive information using techniques such as heap inspection.




Remediation Cost









Automated Detection





CodeSonar4.4(customization)Users can add a custom check for use of realloc().



Could detect possible violations of this rule by first flagging any usage of realloc(). Also, it could flag any usage of free that is not preceded by code to clear out the preceding memory, using memset. This heuristic is imperfect because it flags all possible data leaks, not just leaks of "sensitive" data, because ROSE cannot tell which data is sensitive




LDRA tool suite9.5.644 SEnhanced Enforcement
Polyspace Bug FinderR2016a

Sensitive heap memory not cleared before release

Uncleared sensitive data in stack

Sensitive data not cleared or released by memory routine

Variable in stack is not cleared and contains sensitive data

PRQA QA-C8.2warncall for reallocPartially implemented

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

SEI CERT C++ Coding StandardMEM03-CPP. Clear sensitive information stored in returned reusable resources
ISO/IEC TR 24772:2013Sensitive Information Uncleared Before Use [XZK]
MITRE CWECWE-226, Sensitive information uncleared before release
CWE-244, Failure to clear heap memory before release ("heap inspection")




  1. Need to add some discussion about declaring variables as volatile to prevent compilers from optimizing away memory wipes

  2. This could be an issue on the stack too.  More general principle: clear sensitive info out of all reusable resources (heap, stack, disk sectors, whiteboards, whatever) before returning it to reuse.

    1. My initial reaction is to expand to include "memory" including heap, stack, data segment, etc.

      I don't think we should discuss clearing disk memory, as I think this topic is very complex. For example, I found this quote on the subject: "There is only one real way to really ensure that data can not be accessed. This is to destroy the hard drive in a very hot fire and melt it."

      I think whiteboards are outside of our scope. Once we start talking about mechanisms not defined by the language, the list becomes infinite.

      There are a couple of topics referenced in the Wheeler article above that we may want to consider:

      1. keeping memory form being paged to disk
      2. disabling core dumps.

      The problem with this rule (MEM03-A) is that it is a gateway to a bunch of other rules that talk about various security mechanisms which we have considered out of scope for this project. For example, we don't talk about encryption at all yet.

      1. I didn't mean that we need to delve into the details of the other media.  The main thing I meant was to acknowledge that it's a problem with all media.  Maybe a list ("including but not limited to") of the most common types (such as those mentioned above, plus temp files) would help.  No need to mention whiteboards.  Post-It notes are Right Out.  (big grin)   It could possibly be mentioned that encryption make the data meaningless to other programs, and leave the entire field of encryption as an exercise for the reader.  (wink)

    1. I tried consolidating these and didn't like the result.  It is worthwhile to go into detail on each subject separately rather than merge them into one very long recommendation.

  3. One way to deal with agressive optimization is to use volatile qualification, which a conforming implementation must honor:
    memset((volatile char *)new_secret, '\0', size);

  4. I'm not completely sure the meaning of "regenerative case" in

    Reallocating memory using the realloc() function is a regenerative case of freeing memory.

    Can we rewrite this to the following?

    When reallocating memory using the realloc() function we have the same problem as in freeing memory.

    1. I'm not sure what "regenerative case" means either. (smile) Rewritten.

      1. thanks!  very understandable for me now (-:

        and I separated paragraphs.

  5. At the first Compliant solution the wrong check is not fixed:

    Current version:
    if (size == SIZE_MAX) {
      /* Handle error */
    Must be:
    if (size >= SIZE_MAX) {
      /* Handle error */
    1. SIZE_MAX is the largest value a size_t can hold. Since size is declared as a size_t, there are no values larger than SIZE_MAX that can be stored within the variable, and so == is a correct implementation. Using >= would also be correct, but misleading (and less efficient), since the value could never satisfy the >.

      1. If SIZE_MAX is the largest value a size_t can hold then it will be hard (impossible) to allocate this chunk of memory. (smile)