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

Compare with Current View Page History

« Previous Version 87 Next »

An application programming interface (API) specifies how a function is intended to be called. Calling a function with incorrect arguments can result in unexpected or unintended program behavior. Functions that are appropriately declared (as in DCL07-C. Include the appropriate type information in function declarators) will typically fail compilation if they are supplied with the wrong number or types of arguments. However, there are cases where supplying the incorrect arguments to a function will at best generate compiler warnings. These warnings should be resolved but do not prevent program compilation.(See MSC00-C. Compile cleanly at high warning levels.)

Noncompliant Code Example (Function Pointers)

In this example, the function pointer fp is used to refer to the function strchr(). However, fp is declared without a function prototype. As a result, there is no type checking performed on the call to fp(12,2);.

#include <stdio.h>
#include <string.h>

char *(*fp) ();

int main(void) {
  char *c;
  fp = strchr;
  c = fp(12, 2);
  printf("%s\n", c);
  return 0;
}

Compliant Solution (Function Pointers)

Declaring fp with a function prototype corrects this example.

#include <string.h>

char *(*fp) (const char *, int);

int main(void) {
  char *c;
  fp = strchr;
  c = fp("Hello",'H');
  printf("%s\n", c);
  return 0;
}

Noncompliant Code Example (Variadic Functions)

The POSIX function open() [Open Group 2004] is a variadic function with the following prototype:

int open(const char *path, int oflag, ... );

The open() function accepts a third argument to determine a newly created file's access mode. If open() is used to create a new file, and the third argument is omitted, the file may be created with unintended access permissions. (See FIO06-C. Create files with appropriate access permissions.)

In this noncompliant code example from a vulnerability in the useradd() function of the shadow-utils package CVE-2006-1174 , the third argument to open() has been accidentally omitted.

fd = open(ms, O_CREAT|O_EXCL|O_WRONLY|O_TRUNC);

Note that technically it is also incorrect to pass a third argument to open() when not creating a new file (that is, with the O_CREAT flag not set). A POSIX implementation could, if it wished, return an EINVAL error in this case. However, in practice it is unlikely to cause a problem.

Compliant Solution (Variadic Functions)

To correct this example, a third argument is specified in the call to open().

/* ... */
fd = open(ms, O_CREAT|O_EXCL|O_WRONLY|O_TRUNC, file_access_permissions);
if (fd == -1){
  /* Handle error */
}
/* ... */

Risk Assessment

Calling a function with incorrect arguments can result in unexpected or unintended program behavior.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP37-C

medium

probable

high

P4

L3

Automated Detection

ToolVersionCheckerDescription
GCC4.3.5 

Can detect violation of this rule when the -Wstrict-prototypes flag is used. However, it cannot detect violations involving variadic functions, such as the open() example described earlier.

Compass/ROSE  

can detect some violations of this rule. In particular, it ensures that all calls to open() supply exactly two arguments if the second argument does not involve O_CREAT, and exactly three arguments if the second argument does involve O_CREAT.

LDRA tool suite

9.7.1

41 D
98 S
170 S
496 S

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

Related Vulnerabilities

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

Related Guidelines

CERT C++ Secure Coding StandardEXP37-CPP. Call variadic functions with the arguments intended by the API
ISO/IEC TR 17961(Draft) Calling functions with incorrect arguments [argcomp]
ISO/IEC TR 24772Subprogram signature mismatch [OTR]
MISRA-CRule 16.6
MITRE CWECWE-628, Function call with incorrectly specified arguments

Bibliography

[CVE]CVE-2006-1174
[ISO/IEC 9899:2011]Foreword and Section 6.9.1, "Function Definitions"
[Spinellis 2006]Section 2.6.1, "Incorrect Routine or Arguments"

 

  • No labels