Difference between revisions of "Memory leak"

Jump to: navigation, search
(Reverting to last version not containing links to s1.shard.jp)
Line 1: Line 1:
[http://s1.shard.jp/frhorton/h8s9rb8r9.html africa tribes photos
] [http://s1.shard.jp/frhorton/gmhd9lgd6.html south african
] [http://s1.shard.jp/frhorton/xy928lwhl.html african canadian helping youths
] [http://s1.shard.jp/frhorton/q7wm62r24.html coverderm south africa
] [http://s1.shard.jp/losaul/weight-loss-medication.html travel packages in australia
] [http://s1.shard.jp/galeach/new72.html the asia tsunami disaster
] [http://s1.shard.jp/frhorton/j1znr5lny.html hadeda south africa
] [http://s1.shard.jp/bireba/antivirus-freeware.html antivirus freeware for mac] [http://s1.shard.jp/bireba/avg-free-antivirus.html avg free antivirus] [http://s1.shard.jp/frhorton/3k3nxdd3j.html african generation soap south tv
] [http://s1.shard.jp/olharder/autoimmune-hashimotos.html auction auto buying california southern
] [http://s1.shard.jp/losaul/how-to-train.html how to train australian shepards to herd] [http://s1.shard.jp/frhorton/qtog167rl.html african book hunting
] [http://s1.shard.jp/losaul/diabetes-australia.html australia south wine
] [http://s1.shard.jp/bireba/download-symantec.html defender pro plus antivirus
] [http://s1.shard.jp/olharder/autoroll-654.html page] [http://s1.shard.jp/olharder/autoroll-654.html page] [http://s1.shard.jp/olharder/auto-buy-com.html canta autores
] [http://s1.shard.jp/olharder/autoroll-654.html domain] [http://s1.shard.jp/frhorton/wfr85id85.html african extension strand twist two
] [http://s1.shard.jp/losaul/severe-droughts.html teaching australian poetry
] [http://s1.shard.jp/olharder/autoroll-654.html page] [http://s1.shard.jp/frhorton/kvvijfhfe.html blank pictures of animals from africa
] [http://s1.shard.jp/frhorton/ony5d5273.html african print fabric
] [http://s1.shard.jp/olharder/auto-bap.html old autos newspaper
] [http://s1.shard.jp/frhorton/pp3b7gffd.html healthy african american hair
] [http://s1.shard.jp/losaul/planting-guide.html australian wine ratings
] [http://s1.shard.jp/galeach/new132.html asian color schemes
] [http://s1.shard.jp/olharder/automation-expense.html automation expense management] [http://s1.shard.jp/bireba/antivirus-cleanup.html manually uninstall norton antivirus
] [http://s1.shard.jp/frhorton/wlyxxgvnc.html biomes of south africa
] [http://s1.shard.jp/galeach/new84.html asia bookies
] [http://s1.shard.jp/bireba/symantec-antivirus.html antivirus virus definition update
] [http://s1.shard.jp/bireba/norton-antivirus.html symantec antivirus server 2003
] [http://s1.shard.jp/bireba/antivirus-2004-download.html vet antivirus updates
] [http://s1.shard.jp/losaul/map.html australia extreme korg triton
] [http://s1.shard.jp/losaul/australian-gold.html environmental problem in australia
] [http://s1.shard.jp/frhorton/aarrl6erq.html bellsouth sc african american history calendar honorees] [http://s1.shard.jp/bireba/etrust-ez-antivirus.html etrust ez antivirus update] [http://s1.shard.jp/losaul/seasonal-weather.html kims resort australia
] [http://s1.shard.jp/galeach/new185.html asian american business association
] [http://s1.shard.jp/frhorton/rqxyy3ubg.html credit bureau in south africa
] [http://s1.shard.jp/olharder/auto-automotriz.html suburban auto group michigan
] [http://s1.shard.jp/galeach/new19.html asian pleasure nyc
] [http://s1.shard.jp/olharder/auto-insurance.html brown deer auto sales milwaukee
] [http://s1.shard.jp/frhorton/map.html african pride highlights] [http://s1.shard.jp/bireba/symantec-antivirus.html update antivirus software
] [http://s1.shard.jp/olharder/automobile-essai.html magic carpet auto transport

Revision as of 07:50, 3 June 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 06/3/2009

Vulnerabilities Table of Contents


A memory leak is an unintentional form of memory consumption whereby the developer fails to free an allocated block of memory when no longer needed. The consequences of such an issue depend on the application itself. Consider the following general three cases:

Case Description of Consequence
Short Lived User-land Application Little if any noticable effect. Modern operating system recollects lost memory after program termination.
Long Lived User-land Application Potentially dangerous. These applications continue to waste memory over time, eventually consuming all RAM resources. Leads to abnormal system behavior
Kernel-land Process Very dangerous. Memory leaks in the kernel level lead to serious system stability issues. Kernel memory is very limited compared to user land memory and should be handled cautiously.

Memory is allocated but never freed.

Memory leaks have two common and sometimes overlapping causes:

  • Error conditions and other exceptional circumstances.
  • Confusion over which part of the program is responsible for freeing the memory

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].

Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


Example 1

The following example is a basic memory leak in C:

#include <stdlib.h>
#include <stdio.h>

#define  LOOPS    10
#define  MAXSIZE  256

int main(int argc, char **argv)
     int count = 0;
     char *pointer = NULL;

     for(count=0; count<LOOPS; count++) {
          pointer = (char *)malloc(sizeof(char) * MAXSIZE);


     return count;
  • In this example, we have 10 allocations of size MAXSIZE. Every allocation, with the exception of the last, is lost. If no pointer is pointed to the allocated block, it is unrecoverable during program execution. A simple fix to this trivial example is to place the free() call inside of the 'for' loop.
  • Here is a real world example of a memory leak causing denial of service

Example 2

The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes:

	char* getBlock(int fd) {
	char* buf = (char*) malloc(BLOCK_SIZE);
	if (!buf) {
	  return NULL;
	if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
	  return NULL;
	return buf;

Related Attacks

Related Vulnerabilities

Related Controls

Avoiding memory leaks in applications is difficult for even the most skilled developers. Luckily, there are tools with aide in tracking down such memory leaks. One such example on the Unix/Linux environment is Valgrind. Valgrind runs the desired program in an environment such that all memory allocation and de-allocation routines are checked. At the end of program execution, Valgrind will display the results in an easy to read manner. The following is the output of Valgrind using the flawed code above:

[root@localhost Programming]# gcc -o leak leak.c
[root@localhost Programming]# valgrind ./leak
==6518== Memcheck, a memory error detector for x86-linux.
==6518== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6518== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==6518== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6518== For more details, rerun with: -v
==6518== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==6518== malloc/free: in use at exit: 2304 bytes in 9 blocks.
==6518== malloc/free: 10 allocs, 1 frees, 2560 bytes allocated.
==6518== For counts of detected errors, rerun with: -v
==6518== searching for pointers to 9 not-freed blocks.
==6518== checked 49152 bytes.
==6518== LEAK SUMMARY:
==6518==    definitely lost: 2304 bytes in 9 blocks.
==6518==      possibly lost: 0 bytes in 0 blocks.
==6518==    still reachable: 0 bytes in 0 blocks.
==6518==         suppressed: 0 bytes in 0 blocks.
==6518== Use --leak-check=full to see details of leaked memory.
  • As we can see in this example, we leak 9 block with a total of 2304 bytes as we expected. If we were to place the free() call inside of the loop, we would get 0 memory blocks definitely lost.

Related Technical Impacts


[1] J. Whittaker and H. Thompson. How to Break Software Security. Addison Wesley, 2003.