Attempting to dereference a null pointer results in undefined behavior, typically abnormal program termination.
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.
#define __STDC_WANT_LIB_EXT1__ 1 #include <stdlib.h> errno_t f(void) { png_charp chunkdata; chunkdata = (png_charp)png_malloc(png_ptr, length + 1); /* ... */ return 0; }
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 (POSIX)
This compliant solution ensures that the pointer returned by malloc()
is not null. This practice ensures compliance with MEM32-C. Detect and handle memory allocation errors.
#define __STDC_WANT_LIB_EXT1__ 1 #include <stdlib.h> errno_t f(void) { png_charp chunkdata; chunkdata = (png_charp)png_malloc(png_ptr, length + 1); if (NULL == chunkdata) { return ENOMEM; /* Indicate failure */ } /* ... */ return 0; }
This compliant solution is categorized as a POSIX solution because it returns ENOMEM
, which is defined by POSIX but not by the C Standard.
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.
#include <string.h> #define __STDC_WANT_LIB_EXT1__ 1 #include <stdlib.h> errno_t 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 (POSIX)
This compliant solution ensures the pointer returned by malloc()
is not null. This solution also complies with MEM32-C. Detect and handle memory allocation errors.
#include <string.h> #define __STDC_WANT_LIB_EXT1__ 1 #include <stdlib.h> errno_t f(void) { size_t size = strlen(input_str)+1; str = (char *)malloc(size); if (NULL == str) { return ENOMEM; /* Indicate allocation failure */ } memcpy(str, input_str, size); /* ... */ free(str); str = NULL; /* ... */ return 0; }
This compliant solution is categorized as a POSIX solution because it returns ENOMEM
, which is defined by POSIX but not by the C Standard.
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. Typically, a 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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP34-C | high | likely | medium | P18 | L1 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Compass/ROSE | Can detect violations of this rule. In particular, ROSE ensures that any pointer returned by | ||
| 2017.07 | CHECKED_RETURN NULL_RETURNS REVERSE_INULL FORWARD_NULL | Finds instances where a pointer is checked against Identifies functions that can return a null pointer but are not checked Identifies code that dereferences a pointer and then checks the pointer against Can find the instances where |
Fortify SCA | 5.0 | ||
2024.3 | NPD.* *RNPD.* | ||
9.7.1 | 45 D | Fully implemented | |
PRQA QA-C | Unable to render {include} The included page could not be found. | 0504 | Fully implemented |
Splint | 3.1.1 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
CERT C++ Secure Coding Standard | EXP34-CPP. Ensure a null pointer is not dereferenced |
CERT Oracle Secure Coding Standard for Java | EXP01-J. Never dereference null pointers |
ISO/IEC TR 24772:2013 | Pointer Casting and Pointer Type Changes [HFC] Null Pointer Dereference [XYH] |
ISO/IEC TS 17961 (Draft) | Dereferencing an out-of-domain pointer [nullref] |
MITRE CWE | CWE-476, NULL Pointer dereference |
Bibliography
[Goodin 2009] | |
[Jack 2007] | |
[Liu 2009] | |
[van Sprundel 2006] | |
[Viega 2005] | Section 5.2.18, "Null-Pointer Dereference" |
png_charp