Page History

Attempting to dereference Dereferencing a null pointer results in is undefined behavior, typically .

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().

This solution also ensures that the user_data pointer is not null. Passing a null pointer to memcpy() would produce undefined behavior, even if the number of bytes to copy were 0.  The user_data pointer could be invalid in other ways, such as pointing to freed memory. However there is no portable way to verify that the pointer is valid, other than checking for null.

#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 */
  }
  if (NULL == user_data) {
    /* 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 behaves in an unpredictable mannerexhibits 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);
  /* ... */
  free(c_str);
  c_str = NULL;
  /* ... */
}

Compliant Solution

To correct this error, ensure the This compliant solution ensures that both input_str and the pointer returned by malloc() is are not null. This also ensures compliance with MEM32-C. Detect and handle memory allocation errors.: 

#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 (strNULL == NULLc_str) {
    /* Handle Allocation Errorerror */
  }
  memcpy(c_str, input_str, size);
  /* ... */
  free(c_str);
  c_str = NULL;
  /* ... */
}

Noncompliant Code Example

...

This noncompliant code example can be found in {{example is from a version of drivers/net/tun.c}} and affects Linux kernel 2.6.30 \ [[Goodin 2009|AA. C References#Goodin 2009]\].]:

Code Block
bgColor #FFCCCC lang c
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) && sock_writeable(sk))) mask |= POLLOUT | POLLWRNORM; if (tun->dev->reg_state != NETREG_REGISTERED) mask = POLLERR; tun_put(tun); return mask; }

The vulnerability occurs because sk pointer is initialized to tun->sk before checking if tun is NULL. Of course, this should be done first because the GCC compiler (a null pointer. Because null pointer dereferencing is undefined behavior, the compiler (GCC in this case) can optimize it and completely remove away the if (!tun) check because it is performed after the assignment tun->sk is accessed, implying that tun is non-null. As a result, the above vulnerability can result in this noncompliant code example is vulnerable to a null pointer dereference exploit. Wiki MarkupNormally, null pointer dereference results in access violation and abnormal program termination. However, it is possible to permit null pointer dereferencing on several operating systems, for example, using {{mmap(2)}} with the {{MAP_FIXED}} flag on Linux and Mac OS X or using {{shmat(2)}} with the {{SHM_RND}} flag on Linux \[[Liu 2009|AA. C References#Liu 2009]\, 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. It also adds assertions to document that certain other pointers must not be null.

static unsigned int tun_chr_poll(struct file *file, poll_table * wait)  {
  assert(file);
  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; 

  DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);  assert(tun->dev);
   
  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) &&  
     sock_writeable(sk)))  
    mask |= POLLOUT | POLLWRNORM;  
   
  if (tun->dev->reg_state != NETREG_REGISTERED)  
    mask = POLLERR;  
   
  tun_put(tun);  
  return mask;  
} 

Risk Assessment

sk = tun->sk;
  assert(sk);
  assert(sk->socket);
  /* 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 2007, van 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 Wiki MarkupDereferencing a null pointer results in undefined behavior, typically abnormal program termination. In some situations, however, dereferencing a null pointer can lead to the execution of arbitrary code \[[Jack 07|AA. C References#Jack 07], [van Sprundel 06|AA. C References#van Sprundel 06]\]. 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.

Automated Detection

The LDRA tool suite Version 7.6.0 can detect violations of this rule.

Fortify SCA Version 5.0 can detect violations of this rule.

Splint Version 3.1.1 can detect violations of this rule.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Related Vulnerabilities

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

Other Languages

This rule appears in the C++ Secure Coding Standard as EXP34-CPP. Ensure a null pointer is not dereferenced.

References

\[[Goodin 2009|AA. C References#Goodin 2009]\]
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.3.2.3, "Pointers"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "HFC Pointer casting and pointer type changes" and "XYH Null Pointer Dereference"
\[[Jack 07|AA. C References#Jack 07]\]
\[[Liu 2009|AA. C References#Liu 2009]\]
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 476|http://cwe.mitre.org/data/definitions/476.html], "NULL Pointer Dereference"
\[[van Sprundel 06|AA. C References#van Sprundel 06]\]
\[[Viega 05|AA. C References#Viega 05]\] Section 5.2.18, "Null-pointer dereference"

Related Guidelines

Key here (explains table format and definitions)

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.

Bibliography 

...

Image Added Image Added Image AddedEXP33-C. Do not reference uninitialized memory      03. Expressions (EXP)      EXP35-C. Do not access or modify an array in the result of a function call after a subsequent sequence point