Memory errors

Each of these programs runs to the end without a complaint, and each is wrong. Watch the memory, then read what the tool says.

1#include <stdio.h>2#include <stdlib.h>3 4int main(void)5{6    int *p = malloc(4 * sizeof *p);7    if (p == NULL)8        return 1;9    p[0] = 7;10    p = malloc(4 * sizeof *p);11    if (p == NULL)12        return 1;13    p[0] = 8;14    printf("%d\n", p[0]);15    free(p);16    return 0;17}

Direct leak of 16 byte(s) in 1 object(s) allocated from:

Four mistakes that run

Every program in the switch ran to its last line. Nothing stopped and nothing crashed, and each plain build printed a number as if it were right. That is the trouble with memory mistakes in C: the language does not check how memory is used, so a wrong program usually runs as if it were right.

A leak. In leak.c, p holds the address of the first block. Line 10 stores the address of a second block in p, and the first address is gone: no box holds it any more. The block is still taken, and with its address lost, nothing can ever free it.

A use after free. In use-after-free.c, q is a copy of p, so both point at the block. free(p) gives the block back, and p = NULL clears p. But q still holds 0x1000. Reading q[0] reads memory the program has given away, and what it prints is whatever is there now. Setting p to NULL protected p, and only p.

An uninitialised read. In uninitialised.c, total is declared without a value. Its box holds whatever bytes were left there, and the loop adds 1, 2, 3 and 4 to that. Reading it is undefined behaviour, so C promises nothing about the output. On this machine it printed a number that depended on what was left in the box.

A read past the end. In pointer-past-end.c, p walks along a, as in Arrays and pointer arithmetic (2.3). But the test is p <= a + 5, so p takes one step too many, to a + 5, 0x7fe4 in the picture: the dashed box past a[4]. A pointer may hold that address; it may not be followed. sum += *p follows it, and that is undefined behaviour. On this machine, with this build, it read the 4 bytes after a[4], so the sum came out as 15 plus whatever those bytes held. Written with an index, for (int i = 0; i <= 5; i++) sum += a[i];, the mistake is the same: a[5] reads those 4 bytes too.

The code and its cost

Fixing each one

In the leak’s fix, the first block is freed while p still points at it; a later malloc may then hand the same bytes out again.

Dangling pointers and NULL

A pointer that still holds the address of a freed block is called dangling. Following it, as q[0] does, is a use after free. Calling free on it again is a double free. The C standard leaves both undefined: anything may happen, including nothing visible.

Setting a pointer to NULL right after free helps in two ways. A later free(p) becomes free(NULL), which does nothing. A later *p follows NULL and stops the program at once, at the line that made the mistake. But it helps only for that one pointer. Every other copy of the address, like q, still dangles, and you have to know where those copies are.

Indexing past either end

a[5] goes past the end of int a[5], and a[-1] goes before its start. Both are undefined behaviour. On this machine, with this build, they touch a neighbour: the 4 bytes after a[4] or below a[0], whatever lives there. A write, such as a[5] = 0;, changes it. On the stack, that neighbour may be another variable, or the bytes that say where to return.

The tools

Three kinds of tool catch these mistakes, each some of them.

The compiler’s warnings. Build with -Wall -Wextra. gcc warns about use-after-free.c at once:

use-after-free.c:13:5: warning: pointer 'q' used after 'free' [-Wuse-after-free]

For uninitialised.c it says nothing in a plain build. With optimisation on, -O2, it warns that 'total' is used uninitialized: the warning needs the analysis the optimiser does.

The sanitisers. Build with -fsanitize=address,undefined and run the program. The compiler adds checks around every memory access, and the program reports the first broken rule. AddressSanitizer then stops the program; UndefinedBehaviorSanitizer reports and carries on unless you ask it to halt. AddressSanitizer catches reads and writes outside a block or a stack array, use after free, double free, and, when the program ends, leaks. UndefinedBehaviorSanitizer catches, among other things, an index out of the bounds of an array whose size it knows. For pointer-past-end.c, AddressSanitizer reports the read:

ERROR: AddressSanitizer: stack-buffer-overflow
READ of size 4 thread T0

For the index form, past-the-end.c, UndefinedBehaviorSanitizer reports first:

past-the-end.c:8:17: runtime error: index 5 out of bounds for type 'int [5]'

Neither sanitiser checks reads of uninitialised memory: the run of uninitialised.c reports nothing.

Valgrind is another common tool. It runs the unchanged program on a simulated processor and checks every access as it goes, more slowly.

Reading a report

A report’s first line names the error. For use-after-free.c:

ERROR: AddressSanitizer: heap-use-after-free
READ of size 4 thread T0

The next lines say what was done, a read of 4 bytes, one int, and where: a list of functions, innermost first, each with its file and line. Further down, the report says where the block was freed and where it was allocated. The last line sums it up, here SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:13 in main, the line of the printf.

What the checks cost

A sanitiser build runs more slowly and uses more memory than a plain one, because of the checks it adds. So programmers build with sanitisers while they develop and test, and ship the plain build.

Worked example

A double free. This program frees the same block twice:

int *p = malloc(4 * sizeof *p);
if (p == NULL)
    return 1;
free(p);
free(p);

gcc warns at the second free that p is used after free. The sanitiser build stops with ERROR: AddressSanitizer: attempting double-free. Even the plain build stops here: the C library notices and aborts with free(): double free detected in tcache 2. Put p = NULL; between the two calls and the second becomes free(NULL): the program runs cleanly, under every tool.

A leak, by the hour. A server that leaks the 16 bytes of leak.c on each request, at 1,000 requests a second, loses 16 × 1,000 = 16,000 bytes a second, and 16,000 × 3,600 = 57,600,000 bytes an hour, about 55 MiB. In a day, it is over a gigabyte.

Which tool catches which. From the four pictures:

Neither column says “yes” for every mistake, and the uninitialised read gets nothing from the sanitisers. Use both, and keep the warnings on.

Try it yourself. In use-after-free.c, what does q hold after p = NULL;? 0x1000, unchanged: clearing p did not touch q.

Where it’s used

Crashes far from their cause. A write past the end of a buffer changes a neighbour, and the program fails much later, wherever that neighbour is next used. A sanitiser build stops at the write itself.

Security flaws. In software written in C, a read past an end or through a freed block can be steered by an attacker, who chooses what lies there. Many serious security flaws have been mistakes of exactly these four kinds.

Testing on every change. Projects in C build their tests with sanitisers and run them on every change, so a new memory mistake is caught the day it is written.

Reference card

Platform: C11, gcc 13 on x86-64 Linux, with its sanitisers. The addresses in the pictures are short stand-ins, by one rule for the whole course.