You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 137 Next »

Attempting to dereference a null pointer results in undefined behavior.

On many platforms dereferencing a null pointer results in abnormal program termination, but this is not required by the standard. See [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 MEM32-C. Detect and handle memory allocation errors

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

If length has the value −1, 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. 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 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 */
 
void func(png_structp png_ptr, size_t length) { 
  png_charp chunkdata;
  chunkdata = (png_charp)png_malloc(png_ptr, length + 1);
  if (NULL == chunkdata) {
    /* Handle error */
  }
  /* ... */
}

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 exhibits undefined behavior.  Additionally, if input_str is a null pointer, the call to strlen() dereferences a null pointer, resulting in undefined behavior. This code also violates MEM32-C. Detect and handle memory allocation 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

This compliant solution ensures input_str is non-null, and the pointer returned by malloc() is 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);
  /* ... */
  free(c_str);
  c_str = NULL;
  /* ... */
}

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 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 dereferenced, implying that tun is non-null. As a result, this noncompliant code example is vulnerable to a null pointer dereference exploit, because it is possible to permit null pointer dereferencing on several platforms, 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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP34-C

High

Likely

Medium

P18

L1

Automated Detection

ToolVersionCheckerDescription
Compass/ROSE  

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)

Coverity

 

2017.07

CHECKED_RETURN

NULL_RETURNS

REVERSE_INULL

FORWARD_NULL

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

Fortify SCA

5.0

  
 

Klocwork

 2024.1 

NPD.* *RNPD.*

 

LDRA tool suite

9.7.1

45 D

Fully implemented
PRQA QA-C
Unable to render {include} The included page could not be found.

0504  
0505  
0506  

Fully implemented

Splint

3.1.1  

Related Vulnerabilities

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

Related Guidelines

Bibliography

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

 


png_charp
  • No labels