Redundant Null Check

The program can potentially dereference a null-pointer, which can cause a segmentation fault.

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker might be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer confirms that the object foo is null and subsequently dereferences it erroneously. If foo is null when it is checked in the if statement, then a null dereference occurs, which causes a null-pointer exception.

if (foo is null) {
	foo.SetBar(val);
	...
}

Example 2: In the following code, the programmer assumes that the variable foo is not null and confirms this assumption by dereferencing the object. However, the programmer later contradicts the assumption by checking foo against null. If foo can be null when it is checked in the if statement then it can also be null when it is dereferenced and might cause a null-pointer exception. Either the dereference is unsafe or the subsequent check is unnecessary.

foo.SetBar(val);
...
if (foo is not null) {
	...
}

Example 3: In the following code, the programmer explicitly sets the variable foo to null. Later, the programmer dereferences foo before checking the object for a null value.

Foo foo = null;
...
foo.SetBar(val);
...
}

The program can potentially dereference a null-pointer, thereby causing a segmentation fault.

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the variable ptr is not NULL. That assumption is made explicit when the programmer dereferences the pointer. This assumption is later contradicted when the programmer checks ptr against NULL. If ptr can be NULL when it is checked in the if statement then it can also be NULL when it dereferenced and may cause a segmentation fault.

ptr->field = val;
...
if (ptr != NULL) {
        ...
}

Example 2: In the following code, the programmer confirms that the variable ptr is NULL and subsequently dereferences it erroneously. If ptr is NULL when it is checked in the if statement, then a null dereference will occur, thereby causing a segmentation fault.

if (ptr == null) {
        ptr->field = val;
        ...
}

Example 3: In the following code, the programmer forgets that the string '\0' is actually 0 or NULL, thereby dereferencing a null-pointer and causing a segmentation fault.

if (ptr == '\0') {
        *ptr = val;
        ...
}

Example 4: In the following code, the programmer explicitly sets the variable ptr to NULL. Later, the programmer dereferences ptr before checking the object for a null value.

*ptr = NULL;
...
ptr->field = val;
...
}