Skip to end of metadata
Go to start of metadata

Dereferencing a null pointer is undefined behavior.

On many platforms, dereferencing a null pointer results in abnormal program termination, but this is not required by the standard. See "Clever Attack Exploits Fully-Patched Linux Kernel" [Goodin 2009] for an example of a code execution exploit that resulted from a null pointer dereference.

Noncompliant Code Example

This noncompliant code example is derived from a real-world example taken from a vulnerable version of the libpng library as deployed on a popular ARM-based cell phone [Jack 2007]. The  libpng library allows applications to read, create, and manipulate PNG (Portable Network Graphics) raster image files. The libpng library implements its own wrapper to malloc() that returns a null pointer on error or on being passed a 0-byte-length argument.

This code also violates ERR33-C. Detect and handle standard library errors.

#include <png.h> /* From libpng */
#include <string.h>
void func(png_structp png_ptr, int length, const void *user_data) { 
  png_charp chunkdata;
  chunkdata = (png_charp)png_malloc(png_ptr, length + 1);
  /* ... */
  memcpy(chunkdata, user_data, length);
  /* ... */

If length has the value −1, the addition yields 0, and png_malloc() subsequently returns a null pointer, which is assigned to chunkdata. The chunkdata pointer is later used as a destination argument in a call to memcpy(), resulting in user-defined data overwriting memory starting at address 0. In the case of the ARM and XScale architectures, the 0x0 address is mapped in memory and serves as the exception vector table; consequently, dereferencing 0x0 did not cause an abnormal program termination.

Compliant Solution

This compliant solution ensures that the pointer returned by png_malloc() is not null. It also uses the unsigned type size_t to pass the length parameter, ensuring that negative values are not passed to func().

#include <png.h> /* From libpng */
#include <string.h>

 void func(png_structp png_ptr, size_t length, const void *user_data) { 
  png_charp chunkdata;
  if (length == SIZE_MAX) {
    /* Handle error */
  chunkdata = (png_charp)png_malloc(png_ptr, length + 1);
  if (NULL == chunkdata) {
    /* Handle error */
  /* ... */
  memcpy(chunkdata, user_data, length);
  /* ... */


Noncompliant Code Example

In this noncompliant code example, input_str is copied into dynamically allocated memory referenced by c_str. If malloc() fails, it returns a null pointer that is assigned to c_str. When c_str is dereferenced in memcpy(), the program exhibits undefined behavior.  Additionally, if input_str is a null pointer, the call to strlen() dereferences a null pointer, also resulting in undefined behavior. This code also violates ERR33-C. Detect and handle standard library errors.

#include <string.h>
#include <stdlib.h>
void f(const char *input_str) {
  size_t size = strlen(input_str) + 1;
  char *c_str = (char *)malloc(size);
  memcpy(c_str, input_str, size);
  /* ... */
  c_str = NULL;
  /* ... */

Compliant Solution

This compliant solution ensures that both input_str and the pointer returned by malloc() are not null: 

#include <string.h>
#include <stdlib.h>
void f(const char *input_str) {
  size_t size;
  char *c_str;
  if (NULL == input_str) {
    /* Handle error */
  size = strlen(input_str) + 1;
  c_str = (char *)malloc(size);
  if (NULL == c_str) {
    /* Handle error */
  memcpy(c_str, input_str, size);
  /* ... */
  c_str = NULL;
  /* ... */

Noncompliant Code Example

This noncompliant code example is from a version of drivers/net/tun.c and affects Linux kernel 2.6.30 [Goodin 2009]:

static unsigned int tun_chr_poll(struct file *file, poll_table *wait)  {
  struct tun_file *tfile = file->private_data;
  struct tun_struct *tun = __tun_get(tfile);
  struct sock *sk = tun->sk;
  unsigned int mask = 0;

  if (!tun)
    return POLLERR;

  DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);

  poll_wait(file, &tun->socket.wait, wait);

  if (!skb_queue_empty(&tun->readq))
    mask |= POLLIN | POLLRDNORM;

  if (sock_writeable(sk) ||
     (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) &&

  if (tun->dev->reg_state != NETREG_REGISTERED)
    mask = POLLERR;

  return mask;

The sk pointer is initialized to tun->sk before checking if tun is a null pointer. Because null pointer dereferencing is undefined behavior, the compiler (GCC in this case) can optimize away the if (!tun) check because it is performed after tun->sk is accessed, implying that tun is non-null. As a result, this noncompliant code example is vulnerable to a null pointer dereference exploit, because null pointer dereferencing can be permitted on several platforms, for example, by using mmap(2) with the MAP_FIXED flag on Linux and Mac OS X, or by using the shmat() POSIX function with the SHM_RND flag [Liu 2009].

Compliant Solution

This compliant solution eliminates the null pointer deference by initializing sk to tun->sk following the null pointer check:

static unsigned int tun_chr_poll(struct file *file, poll_table *wait)  {
  struct tun_file *tfile = file->private_data;
  struct tun_struct *tun = __tun_get(tfile);
  struct sock *sk;
  unsigned int mask = 0;

  if (!tun)
    return POLLERR;

  sk = tun->sk;

  /* The remaining code is omitted because it is unchanged... */


Risk Assessment

Dereferencing a null pointer is undefined behavior, typically abnormal program termination. In some situations, however, dereferencing a null pointer can lead to the execution of arbitrary code [Jack 2007van Sprundel 2006]. The indicated severity is for this more severe case; on platforms where it is not possible to exploit a null pointer dereference to execute arbitrary code, the actual severity is low.




Remediation Cost









Automated Detection

null-dereferencingFully checked


Null pointer dereference
Null test after dereference
Unchecked parameter dereference


Can detect violations of this rule. In particular, ROSE ensures that any pointer returned by malloc(), calloc(), or realloc() is first checked for NULL before being used (otherwise, it is free()-ed). ROSE does not handle cases where an allocation is assigned to an lvalue that is not a variable (such as a struct member or C++ function call returning a reference)







Finds instances where a pointer is checked against NULL and then later dereferenced

Identifies functions that can return a null pointer but are not checked

Identifies code that dereferences a pointer and then checks the pointer against NULL

Can find the instances where NULL is explicitly dereferenced or a pointer is checked against NULL but then dereferenced anyway. Coverity Prevent cannot discover all violations of this rule, so further verification is necessary

nullPointer, nullPointerDefaultArg, nullPointerRedundantCheck

Context sensitive analysis

Detects when NULL is dereferenced (Array of pointers is not checked. Pointer members in structs are not checked.)

Finds instances where a pointer is checked against NULL and then later dereferenced

Identifies code that dereferences a pointer and then checks the pointer against NULL

Does not guess that return values from malloc(), strchr(), etc., can be NULL (The return value from malloc() is NULL only if there is OOMo and the dev might not care to handle that. The return value from strchr() is often NULL, but the dev might know that a specific strchr() function call will not return NULL.)



LDRA tool suite

45 D, 123 D, 128 D, 129 D, 130 D, 131 D, 652 S

Fully implemented
Parasoft C/C++test
BD-PB-NPFully implemented
Parasoft Insure++

Runtime analysis
Polyspace Bug FinderR2016a Arithmetic operation with NULL pointer,
Null pointer,
Use of tainted pointer

Arithmetic operation performed on NULL pointer

NULL pointer dereferenced

Pointer from an unsecure source may be NULL or point to unknown memory

2810, 2811, 2812, 2813, 2814, 2820, 2821, 2822, 2823, 2824

2810, 2811, 2812, 2813, 2814, 2820, 2821, 2822, 2823, 2824 

Fully implemented
PVS-Studio6.22V522, V595, V664, V713, V1004
SonarQube C/C++ Plugin

Related Vulnerabilities

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

Related Guidelines

Key here (explains table format and definitions)


Taxonomy item


CERT Oracle Secure Coding Standard for JavaEXP01-J. Do not use a null in a case where an object is requiredPrior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013Pointer Casting and Pointer Type Changes [HFC]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013Null Pointer Dereference [XYH]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TS 17961Dereferencing an out-of-domain pointer [nullref]Prior to 2018-01-12: CERT: Unspecified Relationship
CWE 2.11CWE-476, NULL Pointer Dereference2017-07-06: CERT: Exact

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-690 and EXP34-C

EXP34-C = Union( CWE-690, list) where list =

  • Dereferencing null pointers that were not returned by a function

CWE-252 and EXP34-C

Intersection( CWE-252, EXP34-C) = Ø

EXP34-C is a common consequence of ignoring function return values, but it is a distinct error, and can occur in other scenarios too.


[Goodin 2009]
[Jack 2007]
[Liu 2009]
[van Sprundel 2006]
[Viega 2005]Section 5.2.18, "Null-Pointer Dereference"


  1. Should that be: if (size >= SIZE_MAX) {

    1. I believe in this case, either expression would work.

      SIZE_MAX is the largest possible value that a size_t could take, so it is not possible to have anything larger than SIZE_MAX.

      The test was added to catch the possibly theoretical situation where the length of input_str was somehow the maximum size for size_t, and adding one to this size in the malloc expression (to allocated space for the trailing null byte) results in an integer overflow.

      I say "theoretical" because I have not successfully produced strings of this length in testing.

      1. Ah, gotcha. That makes sense. Yeah, I suspect once it's possible to allocate 2+gigs contiguously in amainstream install of a modern OS, we'll see a frenzy of new vulnerabilities come out. The 4gig boundary will probably be important too with unsigned int in LP64, but since size_t will be 64-bit, there will have to be some truncation that compilers will be able to warn on. (I think you cover that in a different rule.) The above check can't hurt, as I guess you could have a system with a 32-bit size_t that had a ton of memory and had some crazy banking/selector scheme with pointers. It also reinforces the notion to the reader that any time you see arithmetic in an allocation expression, you need to think about corner-cases.

    2. I added a comment to explain that SIZE_MAX is the limit of size_t

  2. In my experience, there are reasons to check for a NULL pointer other than dereferencing it.

    A common memory-leak idiom, is reallocating storage and assigning its address to a pointer that already points to allocated storage. The correct idiom is to only allocate storage if the pointer is currently NULL. But no where in that particular idiom would a NULL pointer necessarily be deferenced.

  3. The article easily misleads the reader into believeing that ensuring pointer validity boils down to checking for pointer being not equal to NULL. Unfortunately the problem is much more complex, and generally unsolvable within standard C. Consider the following example:

    void f(int *x)
      *x = 12;
    void g(void)
      int x, *p = &x;

    There's no way f can check whether x points into valid memory or not. Using platform-specific means (e.g. parsing /proc/self/maps under linux) one might find out whether the pointer points into mapped memory, but this is still not a guarantee of validity because it is very coarse-grained – see again the above example. IMHO, the rule title should be changed to something less general.

    1. That's true.  I've changed it to say null pointer instead of invalid pointer.

  4. It is useful to have a function with portable interface but platform-dependent implementation:

    extern bool invalid(const void *);
    assert(!invalid(p)); // or whatever

    Typical implementation:

    bool invalid(const void *p) {
    extern char _etext;
    return p == NULL || (char *)p < &_etext;

    Note that it doesn't know how to check for non-heap, non-stack.  Many platforms can support testing for those also.

    The idea is not to guarantee validity, but to catch a substantial number of problems that could occur.

  5. Made code more compliant with other rules.

    At this point we define size as strlen(input_str) + 1. Since SIZE_MAX represents the largest possible object, the largest possible string would then be SIZE_MAX-1 characters long (excluding '\0'). So the SIZE_MAX check was unnecessary.

  6. This is a matter of style, and also following code walkthrough.  In the complaint version

    We have mask = 0;

    Then below, first change to mask  is

    mask |= POLLIN | POLLRDNORM;

     I like to make source code checking a little quicker by putting parenthesizes around  arguments to |=  or &=  as

    mask |= (POLLOUT | POLLWRNORM);



  7. The final NCCE is actually more insidious than it seems at first.  Because null pointer dereferencing is UB, the if (!tun) check can be elided entirely by the optimizer (since the tun->sk implies that tun must be non-null).

  8. The 2nd NCCE/CS pair seems redundant with the first NCCE/CS pair.

    1. One could argue that all code examples would be redundant with the first pair.  (smile)  In this case, the difference is the assumption that malloc() always returns non-null for the second NCCE, whereas the first NCCE has the malloc() abstracted away.

  9. I suggest that this topic needs to include calloc() and realloc()   Refer to Linux man pages online  for more enlightenment about malloc(), and friends.  

    I believe that dereferencing NULL should not crash the system, should not allow a write to a NULL pointer area, but should always set errno,  If I am a hacker, could I trap a null failure that would force a memory dump. Could I capture, and I would be able to glean much security information from the dump?   The null pointer check for writing or dereferencing should be a compiler flag or library setting.

    1. This rule applies to all null pointers, regardless of which function returned them. 

      Believing that dereferencing NULL shouldn't crash the system doesn't make it true.  I guess you could write a proposal to modify the C Standard, but our coding standard is meant to provide guidance for the existing language.