EXP34-C. Do not dereference null pointers

Attempting to dereference a null pointer results in undefined behavior, typically abnormal program termination.

Noncompliant Code Example

This noncompliant code example is 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 implements its own wrapper to malloc() that returns a null pointer on error or on being passed a 0 byte length argument.

png_charp chunkdata;
chunkdata = (png_charp)png_malloc(png_ptr, length + 1);

If a length field of −1 is supplied to the code in this noncompliant example, the addition wraps around to 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. A write from or read to the memory address 0x0 will generally reference invalid or unused memory. In the case of the ARM and XScale architectures, the 0x0 address is mapped in memory and serves as the exception vector table.

Compliant Solution

To correct this error, ensure the pointer returned by malloc() is not null. This practice ensures compliance with MEM32-C. Detect and handle memory allocation errors.

png_charp chunkdata;

int f(void) {
  chunkdata = (png_charp)png_malloc(png_ptr, length + 1);
  if (chunkdata == NULL) {
    return -1;  /* Indicate failure */
  }

/* ... */
  return 0;
}

Noncompliant Code Example

In this noncompliant code example, input_str is copied into dynamically allocated memory referenced by str. If malloc() fails, it returns a null pointer that is assigned to str. When str is dereferenced in memcpy(), the program behaves in an unpredictable manner.

int f(void) {
  size_t size = strlen(input_str)+1;
  str = (char *)malloc(size);
  memcpy(str, input_str, size);
/* ... */
  free(str);
  str = NULL;

 
  return 0;
}

Compliant Solution

To correct this error, ensure the pointer returned by malloc() is not null. This practice also ensures compliance with MEM32-C. Detect and handle memory allocation errors.

int f(void) {
  size_t size = strlen(input_str)+1;
  str = (char *)malloc(size);
  if (str == NULL) {
    return -1; /* Indicate allocation failure */
  }
  memcpy(str, input_str, size);
/* ... */
  free(str);
  str = NULL;

/* ... */
  return 0;
}

Noncompliant Code Example

This noncompliant code example can be found in 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) &&
     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 is initialized to tun->sk before checking if tun is equal to NULL. Of course, this should be done first because the GCC compiler (in this case) optimizes it and completely removes the if (!tun) check because it is performed after the assignment. As a result, the above vulnerability can result in a null pointer dereference exploit.

Normally, 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].

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;

  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;
}

Risk Assessment

Dereferencing 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 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 low.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

png_charp