NULL Pointer Dereference

A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.


Description

NULL pointer dereference issues can occur through a number of flaws, including race conditions, and simple programming omissions.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

While there are no complete fixes aside from conscientious programming, the following steps will go a long way to ensure that NULL pointer dereferences do not occur.

if (pointer1 != NULL) {


  /* make use of pointer1 */

  /* ... */


}

If you are working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished.

Example Two

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

void host_lookup(char *user_supplied_addr){

  struct hostent *hp;
  in_addr_t *addr;
  char hostname[64];
  in_addr_t inet_addr(const char *cp);

  /*routine that ensures user_supplied_addr is in the right format for conversion */

  validate_addr_form(user_supplied_addr);
  addr = inet_addr(user_supplied_addr);
  hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
  strcpy(hostname, hp->h_name);

}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example Three

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method.

String cmd = System.getProperty("cmd");
cmd = cmd.trim();

Example Four

This Android application has registered to handle a URL when sent an intent:

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {

  @Override
  public void onReceive(Context context, Intent intent) {

    if("com.example.URLHandler.openURL".equals(intent.getAction())) {
      String URL = intent.getStringExtra("URLToOpen");
      int length = URL.length();

    ...
    }

  }

}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Example Five

Consider the following example of a typical client server exchange. The HandleRequest function is intended to perform a request and use a defer to close the connection whenever the function returns.

func HandleRequest(client http.Client, request *http.Request) (*http.Response, error) {
  response, err := client.Do(request)
  defer response.Body.Close()
  if err != nil {
    return nil, err

  }
  ...

}

If a user supplies a malformed request or violates the client policy, the Do method can return a nil response and a non-nil err.

This HandleRequest Function evaluates the close before checking the error. A deferred call's arguments are evaluated immediately, so the defer statement panics due to a nil response.

See Also

Comprehensive Categorization: Poor Coding Practices

Weaknesses in this category are related to poor coding practices.

CISQ Quality Measures - Reliability

Weaknesses in this category are related to the CISQ Quality Measures for Reliability. Presence of these weaknesses could reduce the reliability of the software.

SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)

Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT C Coding Standard.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses

CWE entries in this view are listed in the 2023 CWE Top 25 Most Dangerous Software Weaknesses.

Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses

CWE entries in this view are listed in the 2022 CWE Top 25 Most Dangerous Software Weaknesses.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.