Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
bgColor#FFcccc
langc
#include <locale.h>
#include <stdlib.h>
 
size_t utf8_to_ucs(wchar_t *ucs, size_t n, const char *utf8) {
  setlocale(LC_CTYPE, "en_US.UTF-8");
  return mbstowcs(ucs, utf8, n);
}

...

Code Block
bgColor#ccccFF
langc
#include <locale.h>
#include <stdlib.h>
 
size_t utf8_to_ucs(wchar_t *ucs, size_t n, const char *utf8) {
  const char *save;
  save = setlocale(LC_CTYPE, "en_US.UTF-8");
  if (NULL == save) {
    /* Propagate error to caller. */
    return (size_t)-1;
  }

  n = mbstowcs(ucs, utf8, n);
  if (NULL == setlocale(LC_CTYPE, save))
    n = -1;

  return n;
}

...

Code Block
bgColor#FFcccc
langc
#include <signal.h>
 
volatile sig_atomic_t interrupted;

void handle_interrupt(int signo) {
  interrupted = 1;
}

int f() {
  int result = 0;

  signal(SIGINT, handle_interrupt);

  while (0 == result && 0 == interrupted) {
    /* Perform a lengthy computation. */
  }

  /* Indicate success or failure. */
  return interrupted ? -1 : result;
}

...

Code Block
bgColor#ccccFF
langc
#include <signal.h>
 
volatile sig_atomic_t interrupted;

void handle_interrupt(int signo) {
  interrupted = 1;
}

int f() {
  int result = 0;
  void (*saved_handler)(int);
  saved_handler = signal(SIGINT, handle_interrupt);

  if (SIG_ERR == saved_handler) {
    /* Indicate failure */
    return -1;
  }

  while (0 == result && 0 == interrupted) {
    /* Perform a lengthy computation. */
  }

  if (SIG_ERR == signal(SIGINT, saved_handler))
    return -1;

  /* Indicate success or failure. */
  return interrupted ? -1 : result;
}

...

Code Block
bgColor#FFCCCC
langc
signal_info * start = malloc(num_of_records * sizeof(signal_info));
signal_info * point = (signal_info *)start;
point = start + temp_num - 1; 
memcpy(point->sig_desc, tmp2, strlen(tmp2));
/* ... */ 

When malloc() fails, it returns a null pointer that is assigned to start. If start is a null, an attacker can provide a value for temp_num that, when scaled by the the sizeof signal_info, references a writable address to which control is eventually transferred. The contents of the string referenced by tmp2 can then be used to overwrite the address, resulting in an arbitrary code execution vulnerability.

Compliant Solution (malloc())

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

Code Block
bgColor#ccccff
langc
signal_info * start = malloc(num_of_records * sizeof(signal_info));
if (start == NULL) {
  /* Handle allocation error */
}
signal_info * point = (signal_info *)start;
point = start + temp_num - 1; 
#include <stdlib.h>
#include <string.h>
 
typedef struct {
  char sig_desc[32];
} signal_info;
 
void func(size_t num_of_records, size_t temp_num,
          const char *tmp2) {
  signal_info *start = (signal_info *)malloc(num_of_records *
                                          sizeof(signal_info));
  signal_info *point = start + temp_num - 1; 
  memcpy(point->sig_desc, tmp2, strlen(tmp2));
  /* ... */ 
}

Noncompliant Code Example (malloc())

In this noncompliant code example, input_string is copied into dynamically allocated memory referenced by str. However, the result of malloc() is not checked before str is referenced. Consequently, if malloc() fails, the program has undefined behavior. (See undefined behavior 109 in Annex J of the C Standard.) In practice, an abnormal termination of the process typically occurs, providing an opportunity for a denial-of-service attack. In some cases, it may be the source of other vulnerabilities, as well. (See the Related Vulnerabilities section.) See also MEM32-C. Detect and handle memory allocation errors.

Code Block
bgColor#FFcccc
langc
void f(char *input_string) {
  size_t size = strlen(input_string) + 1;
  char *str = (char *)malloc(size);
  strcpy(str, input_string);
  /* ... */
}

...

When malloc() fails, it returns a null pointer that is assigned to start. If start is a null, an attacker can provide a value for temp_num that, when scaled by the the sizeof signal_info, references a writable address to which control is eventually transferred. The contents of the string referenced by tmp2 can then be used to overwrite the address, resulting in an arbitrary code execution vulnerability.

Compliant Solution (malloc())

To correct this error, ensure the pointer returned by malloc() is not null.

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
#include <string.h>
 
typedef struct {
  char sig_desc[32];
} signal_info;
 
void func(size_t num_of_records, size_t temp_num,
          const char *tmp2) {
  signal_info *point;
  signal_info *start = (signal_info *)malloc(num_of_records *
                                           sizeof(signal_info)

...

Compliant Solution (malloc())

The malloc() function, as well as the other memory allocation functions, returns either a null pointer or a pointer to the allocated space. Always test the returned pointer to ensure it is not null before referencing the pointer. Handle the error condition appropriately when the returned pointer is null. When recovery from the allocation failure is not possible, propagate the failure to the caller.

Code Block
bgColor#ccccff
langc
int f(char *input_string) {
  size_t size = strlen(input_string) + 1;
  char *str = (char *)malloc(size);
  if (strstart == NULL) {
    /* Handle allocation failure and return error status */
    return -1;
  }
  strcpy(str, input_stringerror. */
  }
  point = start + temp_num - 1; 
  memcpy(point->sig_desc, tmp2, strlen(tmp2));
  /* ... */
  free(str);
  return 0;
}
 

}

Noncompliant Code Example (

...

malloc())

This In this noncompliant code example calls realloc() to resize the memory referred to by p. However, if realloc() fails, it returns a null pointer. Consequently, the connection between the original block of memory and p is severed, resulting in a memory leak., input_string is copied into dynamically allocated memory referenced by str. However, the result of malloc() is not checked before str is referenced. Consequently, if malloc() fails, the program has undefined behavior. (See undefined behavior 109 in Annex J of the C Standard.) In practice, an abnormal termination of the process typically occurs, providing an opportunity for a denial-of-service attack. In some cases, it may be the source of other vulnerabilities, as well. (See the Related Vulnerabilities section.)

Code Block
bgColor#FFcccc
langc
#include <stdlib.h>
#include <string.h>
 
void f(char *p;
input_string) {
  size_t new_size = /* nonzero size */;

pstrlen(input_string) + 1;
  char *str = realloc(p, new_char *)malloc(size);
if  strcpy(p == NULL)   {
 str, input_string);
  /* Handle... error */
}

...

Anchor
cs_reallocmalloc
cs_reallocmalloc

Compliant Solution (

...

malloc())

In this compliant solution, the result of realloc() is assigned to the temporary pointer q and validated before it is assigned to the original pointer p:The malloc() function, as well as the other memory allocation functions, returns either a null pointer or a pointer to the allocated space. Always test the returned pointer to ensure it is not null before referencing the pointer. Handle the error condition appropriately when the returned pointer is null. When recovery from the allocation failure is not possible, propagate the failure to the caller.

Code Block
bgColor#ccccff
langc
void *p;
void *q;
#include <stdlib.h>
#include <string.h>
 
int f(char *input_string) {
  size_t new_size = /* nonzero size */;

q strlen(input_string) + 1;
  char *str = realloc(p, new_char *)malloc(size);
  if (qstr == NULL) {
  {
  /* Handle allocation failure and return error status. */
}
else {
  p =return q-1;
}
  }
  strcpy(str, input_string);
  /* ... */
  free(str);
  return 0;
}

Noncompliant Code Example (

...

realloc())

In this This noncompliant code example , the fseekcalls realloc() function is used to set the file position to a location offset in the file referred to by file prior to reading a sequence of bytes from the file. However, if an I/O error occurs during the seek operation the subsequent read will fill the buffer with the wrong contents to resize the memory referred to by p. However, if realloc() fails, it returns a null pointer. Consequently, the connection between the original block of memory and p is severed, resulting in a memory leak.

Code Block
bgColor#ffcccc#FFcccc
langc
size_t read_at(FILE *file, long offset, void *buf, #include <stdlib.h>
 
void *p;
void func(size_t nbytesnew_size) {
  p = fseekrealloc(filep, offset, SEEK_SETnew_size);
  returnif fread(buf, 1, nbytes, file);
}

Compliant Solution (fseek())

(p == NULL)   {
   /* Handle error */
  }
}

When using realloc(), it is important to account for 0-byte allocations. (See MEM04-C. Do not perform zero-length allocations.)

Anchor
cs_realloc
cs_realloc

Compliant Solution (realloc())

In this compliant solution, the result of realloc() is assigned to the temporary pointer q and validated before it is assigned to the original pointer p:According to the C Standard, the fseek() function returns a nonzero value to indicate that an error occurred. Testing for this condition before proceeding to read from the file eliminates the chance of operating on the wrong portion of the file if fseek() failed. Always test the returned value to make sure an error did not occur before operating on the file. If an error does occur, handle it appropriately.

Code Block
bgColor#ccccff
langc
size_t read_at(FILE *file, long offset, void *buf, #include <stdlib.h>
 
void *p;
void func(size_t nbytesnew_size) {
  void *q;

  ifq = realloc(fseek(filep, offset, SEEK_SET) != 0) new_size);
  if (q == NULL)   {
    /* IndicateHandle error */
  to} callerelse */{
    returnp = 0q;
  }
  return fread(buf, 1, nbytes, file);
}
}

Noncompliant Code Example (

...

fseek())

In the following this noncompliant code example,  snprinf() is assumed to succeedthe fseek() function is used to set the file position to a location offset in the file referred to by file prior to reading a sequence of bytes from the file. However, if the call fails (for example, because of insufficient memory, as described in GNU libc bug 441945), the subsequent call to log_message() is likely to result in undefined behavior because the character buffer is not initialized and need not be null-terminatedan I/O error occurs during the seek operation the subsequent read will fill the buffer with the wrong contents.

Code Block
bgColor#ffcccc
langc
extern void log_message(const char*);

void f(int i, int width, int prec) {
  char buf[40];
  snprintf(buf, sizeof buf, "i = %*.*i", width, prec, i);
  log_message(buf);
  /* ... */#include <stdio.h>
 
size_t read_at(FILE *file, long offset, void *buf,
               size_t nbytes) {
  fseek(file, offset, SEEK_SET);
  return fread(buf, 1, nbytes, file);
}

Compliant Solution (

...

fseek())

A compliant solution avoids assuming that snprintf() succeeds regardless of its arguments and tests the return value of the function before using the buffer the function was passed to format output into. In addition, a compliant solution takes care to null-terminate the formatted string in case the provided buffer wasn't large enough for snprintf() to append the terminating nullAccording to the C Standard, the fseek() function returns a nonzero value to indicate that an error occurred. Testing for this condition before proceeding to read from the file eliminates the chance of operating on the wrong portion of the file if fseek() failed. Always test the returned value to make sure an error did not occur before operating on the file. If an error does occur, handle it appropriately.

Code Block
bgColor#ccccff
langc
extern void log_message(const char*);

void f(int i, int width, int prec) {
  char buf[40];
  int n;
  n = snprintf(buf, sizeof buf, "i = %*.*i", width, prec, i);#include <stdio.h>
 
size_t read_at(FILE *file, long offset, void *buf,
               size_t nbytes) {
  if (n < 0) fseek(file, offset, SEEK_SET) != 0) {
    /* Indicate Handleerror snprintf() errorto caller. */
    strcpy(buf, "unknown error")return 0;
  }

  /* Null-terminate buffer in case of overflow */
  buf[sizeof buf - 1] = '\0';    
  log_message(bufreturn fread(buf, 1, nbytes, file);
}

When the length of the formatted string is unbounded, it is best to invoke the function twice, once with a NULL buffer to determine the size of output, then dynamically allocate a buffer of sufficient size, and finally call snprintf() again to format the output into the dynamically allocated buffer. Even with this approach the success of all calls still needs to be tested, and any errors still need to be appropriately handled. A possible optimization is to first attempt to format the string into a reasonably small buffer allocated on the stack and only when the buffer turns out to be too small allocate one of a sufficient size dynamically. This approach is shown in the following compliant solution:

Noncompliant Code Example (snprintf())

In the following noncompliant code example, snprinf() is assumed to succeed. However, if the call fails (for example, because of insufficient memory, as described in GNU libc bug 441945), the subsequent call to log_message() is likely to result in undefined behavior because the character buffer is not initialized and need not be null-terminated.

Code Block
bgColor#ffcccc
langc
#include <stdio.h>
 
extern void log_message(const char *);

void f(int
Code Block
bgColor#ccccff
langc
void f(int i, int width, int prec) {
  char bufferbuf[2040];
  char *snprintf(buf = buffer;
  int n  = sizeof buffer;
  const char fmt[] = , sizeof(buf), "i = %*.*i";

  n = snprintf(buf, n, fmt, width, prec, i);
  if (n < 0) {log_message(buf);
    /* Handle snprintf() error... */
    strcpy(buffer, "unknown error");
    goto write_log;
  }

  if (n < sizeof buffer)
    goto write_log;

  buf = (char*)malloc(n + 1);
  if (NULL == buf) {
    /* Handle malloc() error */
    strcpy(buffer, "unknown error");
    goto write_log;
  }

}

Compliant Solution (snprintf())

A compliant solution avoids assuming that snprintf() succeeds regardless of its arguments and tests the return value of the function before using the buffer the function was passed to format output into. In addition, a compliant solution takes care to null-terminate the formatted string in case the provided buffer wasn't large enough for snprintf() to append the terminating null.

Code Block
bgColor#ccccff
langc
#include <stdio.h>
#include <string.h>
 
extern void log_message(const char *);

void f(int i, int width, int prec) {
  char buf[40];
  int n;
  n = snprintf(buf, nsizeof(buf), fmt"i = %*.*i", width, prec, i);
  if (n < 0) {
    /* Handle snprintf() error. */
    strcpy(bufferbuf, "unknown error");
  }

write_log:
  log_message(buf);

  if (buf != buffer)
    free  /* Null-terminate buffer in case of overflow. */
  buf[sizeof(buf) - 1] = '\0';    
  log_message(buf);
}

Note that this solution correctly handles memory allocation errors in accordance with MEM32-C. Detect and handle memory allocation errors and uses the goto statement as suggested in MEM12-C. Consider using a goto chain when leaving a function on error when using and releasing resources.

Implementation Details

POSIX

In addition to the C standard library functions mentioned earlier, the following functions defined in POSIX require error checking (list is not all-inclusive).

Function

Successful Return

Error Return

errno

fmemopen()

Pointer to a FILE object

NULL

ENOMEM

open_memstream()

Pointer to a FILE object

NULL

ENOMEM

posix_memalign()

0

Nonzero

Unchanged

Setting errno is a POSIX [ISO/IEC 9945:2008] extension to the C Standard.  On error, posix_memalign() returns a value that corresponds to one of the constants defined in the <errno.h> header. The function does not set errno. The posix_memalign() function is optional and is not required to be provided by POSIX-conforming implementations.

Noncompliant Code Example (POSIX)

In the following noncompliant code example, fmemopen() and open_memstream() are assumed to succeed. However, if the calls fail, the two file pointers in and out will be null and the program will have undefined behavior.

Code Block
bgColor#ffcccc
langc
int main(int argc, char *argv[])
{
FILE *out;
FILE *in;
 
if (argc != 2) {
	/* Handle error */
}
 
in = fmemopen(argv[1], strlen(argv[1]), "r"); /* violation */
/* Use in */
 
out = open_memstream(&ptr, &size); /* violation */
/* Use out */
 
}

Compliant Solution (POSIX)

A compliant solution avoids assuming that fmemopen() and open_memstream() succeed regardless of its arguments and tests the return value of the function before using the file pointers in and out:

Code Block
bgColor#ccccff
langc
int main(int argc, char *argv[])
{
FILE *out;
FILE *in;
 
if (argc != 2) {
	/* Handle error */
}
 
in = fmemopen(argv[1], strlen(argv[1]), "r");


if (in == NULL){
	/* Handle error */
}
/* Use in */
 
out = open_memstream(&ptr, &size);

if (out == NULL){
	/* Handle error */

}
/* Use out */
 
}

Exceptions

EXP12-EX1: The exception from EXP12-C. Do not ignore values returned by functions still applies. If the return value is inconsequential or if any errors can be safely ignored, such as for functions called because of their side effects, the function should be explicitly cast to void to signify programmer intent. For an example of this exception, see "Compliant Solution (Remove Existing Destination File)" under "Portable Behavior" in FIO10-C. Take care when using the rename() function.

ERR33-EX1: Ignore the return value of a function that cannot fail or whose return value cannot signify an error condition need not be diagnosed. For example, strcpy() is one such function.

Return values from the following functions do not need to be checked because their historical use has overwhelmingly omitted error checking, and the consequences are not relevant to security.

Function

Successful Return

Error Return

printf()

Number of characters (nonnegative)

Negative

putchar()

Character written

EOF

puts()

Nonnegative

EOF (negative)

putwchar()

Wide character written

WEOF

vprintf()

Number of characters (nonnegative)

Negative

vwprintf()

Number of wide characters (nonnegative)

Negative

wprintf()

Number of wide characters (nonnegative)

Negative

Risk Assessment

Failing to detect error conditions can lead to unpredictable results, including abnormal program termination and denial-of-service attacks or, in some situations, could even allow an attacker to run arbitrary code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

ERR33-C

high

likely

medium

P18

L1

Automated Detection

...

Tool

...

Version

...

Checker

...

Description

...

Compass/ROSE

...

Can detect violations of this recommendation when checking for violations of EXP12-C. Do not ignore values returned by functions and EXP34-C. Do not dereference null pointers

...

Coverity

...

CHECKED_RETURN

...

Finds inconsistencies in how function call return values are handled. Coverity Prevent cannot discover all violations of this recommendation, so further verification is necessary

When the length of the formatted string is unbounded, it is best to invoke the function twice, once with a NULL buffer to determine the size of output, then dynamically allocate a buffer of sufficient size, and finally call snprintf() again to format the output into the dynamically allocated buffer. Even with this approach the success of all calls still needs to be tested, and any errors still need to be appropriately handled. A possible optimization is to first attempt to format the string into a reasonably small buffer allocated on the stack and only when the buffer turns out to be too small allocate one of a sufficient size dynamically. This approach is shown in the following compliant solution:

Note that this solution uses the goto statement as suggested in MEM12-C. Consider using a goto chain when leaving a function on error when using and releasing resources.

Implementation Details

POSIX

In addition to the C standard library functions mentioned earlier, the following functions defined in POSIX require error checking (list is not all-inclusive).

Code Block
bgColor#ccccff
langc
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
extern void log_message(const char *); 
 
void f(int i, int width, int prec) {
  char buffer[20];
  char *buf = buffer;
  int n  = sizeof(buffer);
  const char fmt[] = "i = %*.*i";

  n = snprintf(buf, n, fmt, width, prec, i);
  if (n < 0) {
    /* Handle snprintf() error. */
    strcpy(buffer, "unknown error");
    goto write_log;
  }

  if (n < sizeof(buffer)) {
    goto write_log;
  }

  buf = (char *)malloc(n + 1);
  if (NULL == buf) {
    /* Handle malloc() error. */
    strcpy(buffer, "unknown error");
    goto write_log;
  }

  n = snprintf(buf, n, fmt, width, prec, i);
  if (n < 0) {
    /* Handle snprintf() error. */
    strcpy(buffer, "unknown error");
  }

write_log:
  log_message(buf);

  if (buf != buffer) {
    free(buf);
  }
}

Function

Successful Return

Error Return

errno

fmemopen()

Pointer to a FILE object

NULL

ENOMEM

open_memstream()

Pointer to a FILE object

NULL

ENOMEM

posix_memalign()

0

Nonzero

Unchanged

Setting errno is a POSIX [ISO/IEC 9945:2008] extension to the C Standard.  On error, posix_memalign() returns a value that corresponds to one of the constants defined in the <errno.h> header. The function does not set errno. The posix_memalign() function is optional and is not required to be provided by POSIX-conforming implementations.

Noncompliant Code Example (POSIX)

In the following noncompliant code example, fmemopen() and open_memstream() are assumed to succeed. However, if the calls fail, the two file pointers in and out will be null and the program will have undefined behavior.

Code Block
bgColor#ffcccc
langc
#include <stdio.h>
#include <string.h>
 
int main(int argc, char *argv[]) {
  FILE *out;
  FILE *in;
  size_t size;
  char *ptr;
 
  if (argc != 2) {
    /* Handle error */
  }
 
  in = fmemopen(argv[1], strlen(argv[1]), "r");
  /* Use in */
 
  out = open_memstream(&ptr, &size);
  /* Use out */
 
  return 0; 
}

Compliant Solution (POSIX)

A compliant solution avoids assuming that fmemopen() and open_memstream() succeed regardless of its arguments and tests the return value of the function before using the file pointers in and out:

Code Block
bgColor#ccccff
langc
#include <stdio.h>
#include <string.h>
 
int main(int argc, char *argv[]) {
  FILE *out;
  FILE *in;
  size_t size;
  char *ptr;
 
  if (argc != 2) {
    /* Handle error */
  }
 
  in = fmemopen(argv[1], strlen(argv[1]), "r");

  if (in == NULL){
    /* Handle error */
  }
  /* Use in */
 
  out = open_memstream(&ptr, &size);

  if (out == NULL){
    /* Handle error */
  }
  /* Use out */
  return 0;
}

Exceptions

EXP12-EX1: The exception from EXP12-C. Do not ignore values returned by functions still applies. If the return value is inconsequential or if any errors can be safely ignored, such as for functions called because of their side effects, the function should be explicitly cast to void to signify programmer intent. For an example of this exception, see "Compliant Solution (Remove Existing Destination File)" under "Portable Behavior" in FIO10-C. Take care when using the rename() function.

ERR33-EX1: Ignore the return value of a function that cannot fail or whose return value cannot signify an error condition need not be diagnosed. For example, strcpy() is one such function.

Return values from the following functions do not need to be checked because their historical use has overwhelmingly omitted error checking, and the consequences are not relevant to security.

Function

Successful Return

Error Return

printf()

Number of characters (nonnegative)

Negative

putchar()

Character written

EOF

puts()

Nonnegative

EOF (negative)

putwchar()

Wide character written

WEOF

vprintf()

Number of characters (nonnegative)

Negative

vwprintf()

Number of wide characters (nonnegative)

Negative

wprintf()

Number of wide characters (nonnegative)

Negative

Risk Assessment

Failing to detect error conditions can lead to unpredictable results, including abnormal program termination and denial-of-service attacks or, in some situations, could even allow an attacker to run arbitrary code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

ERR33-C

high

likely

medium

P18

L1

Automated Detection

Tool

Version

Checker

Description

...

Fortify SCA

...

5.0

...

 

...

LDRA tool suite

...

80 D

...

3200

...

Related Coding Practices

FLP03 Detect and handle floating-point errors

Coding Practice

Severity

Likelihood

Remediation Cost

Priority

Level

Compass/ROSE

  

Can detect violations of this recommendation when checking for violations of

EXP12-C. Do not ignore values returned by functions

medium

unlikely

medium

P2

L3

and EXP34-C.

low

probable

high

P2

L3

FLP32-C. Prevent or detect domain and range errors in math functions

medium

probable

medium

P8

L2

MEM32-C. Detect and handle memory allocation errors

high

likely

medium

P18

L1

FIO04-C. Detect and handle input and output errors

medium

probable

high

P4

L3

FIO33-C. Detect and handle input output errors resulting in undefined behavior

high

probable

medium

P12

L1

Do not dereference null pointers

Coverity

Include Page
Coverity_V
Coverity_V

CHECKED_RETURN

Finds inconsistencies in how function call return values are handled. Coverity Prevent cannot discover all violations of this recommendation, so further verification is necessary

Fortify SCA

5.0

 

 

LDRA tool suite

Include Page
LDRA_V
LDRA_V

80 D

Partially implemented
PRQA QA-C
Include Page
PRQA_V
PRQA_V

3200

Partially implemented

Related Vulnerabilities

The vulnerability in Adobe Flash [VU#159523] arises because Flash neglects to check the return value from calloc(). Even when calloc() returns NULL, Flash writes to an offset from the return value. Dereferencing NULL usually results in a program crash, but dereferencing an offset from NULL allows an exploit to succeed without crashing the program.

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

Related Guidelines

Related Vulnerabilities

The vulnerability in Adobe Flash [VU#159523] arises because Flash neglects to check the return value from calloc(). Even when calloc() returns NULL, Flash writes to an offset from the return value. Dereferencing NULL usually results in a program crash, but dereferencing an offset from NULL allows an exploit to succeed without crashing the program.

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

Related Guidelines

...

[DHS 2006]Handle All Errors Safely
[Henricson 1997]Recommendation 12.1, "Check for All Errors Reported from Functions"
[ISO/IEC 9899:2011]Section Subclause 7.21.7.10, "The ungetc Function"

 

...