CERT
Skip to end of metadata
Go to start of metadata

The variable parameters of a variadic function—that is, those that correspond with the position of the ellipsis—are interpreted by the va_arg() macro. The va_arg() macro is used to extract the next argument from an initialized argument list within the body of a variadic function implementation. The size of each parameter is determined by the specified type. If the type is inconsistent with the corresponding argument, the behavior is undefined and may result in misinterpreted data or an alignment error (see EXP36-C. Do not cast pointers into more strictly aligned pointer types).

The variable arguments to a variadic function are not checked for type by the compiler. As a result, the programmer is responsible for ensuring that they are compatible with the corresponding parameter after the default argument promotions:

  • Integer arguments of types ranked lower than int are promoted to int if int can hold all the values of that type; otherwise, they are promoted to unsigned int (the integer promotions).
  • Arguments of type float are promoted to double.

Noncompliant Code Example (Type Interpretation Error)

The C printf() function is implemented as a variadic function. This noncompliant code example swaps its null-terminated byte string and integer parameters with respect to how they are specified in the format string. Consequently, the integer is interpreted as a pointer to a null-terminated byte string and dereferenced, which will likely cause the program to abnormally terminate. Note that the error_message pointer is likewise interpreted as an integer.

Compliant Solution (Type Interpretation Error)

This compliant solution modifies the format string so that the conversion specifiers correspond to the arguments:

As shown, care must be taken to ensure that the arguments passed to a format string function match up with the supplied format string.

Noncompliant Code Example (Type Alignment Error)

In this noncompliant code example, a type long long integer is incorrectly parsed by the printf() function with a %d specifier. This code may result in data truncation or misrepresentation when the value is extracted from the argument list.

Because a long long was not interpreted, if the long long uses more bytes for storage, the subsequent format specifier %s is unexpectedly offset, causing unknown data to be used instead of the pointer to the message.

Compliant Solution (Type Alignment Error)

This compliant solution adds the length modifier ll to the %d format specifier so that the variadic function parser for printf() extracts the correct number of bytes from the variable argument list for the long long argument:

Noncompliant Code Example (NULL)

Because the C Standard allows NULL to be either an integer constant or a pointer constant, any architecture in which int is not the same size as a pointer might present a particular vulnerability with variadic functions. If NULL is defined as an int on such a platform, then sizeof(NULL) != sizeof(void *), so variadic functions that accept an argument of pointer type will not correctly promote NULL to the correct size. Consequently, the following code will have undefined behavior:

On a system with 32-bit int and 64-bit pointers, printf() may interpret the NULL as high-order bits of the pointer and the third argument 1 as the low-order bits of the pointer. In this case, printf() will print a pointer with the value 0x00000001 and then attempt to read an additional argument for the %d conversion specifier, which was not provided.

Compliant Solution (NULL)

This compliant solution avoids sending NULL to printf():

Risk Assessment

Inconsistent typing in variadic functions can result in abnormal program termination or unintended information disclosure.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

DCL11-C

High

Probable

High

P6

L2

Automated Detection

Tool

Version

Checker

Description

Compass/ROSE

 

 

Does not currently detect violations of this recommendation. Although the recommendation in general cannot be automated, because of the difficulty in enforcing contracts between a variadic function and its invokers, it would be fairly easy to enforce type correctness on arguments to the printf() family of functions

ECLAIR

1.2

CC2.DCL11

Partially implemented

GCC4.3.5

 

Warns about inconsistently typed arguments to formatted output functions when the -Wall is used

Klocwork2017

MISRA.FUNC.VARARG
SV.FMT_STR.PRINT_FORMAT_MISMATCH.BAD
SV.FMT_STR.PRINT_FORMAT_MISMATCH.UNDESIRED
SV.FMT_STR.SCAN_FORMAT_MISMATCH.BAD
SV.FMT_STR.SCAN_FORMAT_MISMATCH.UNDESIRED
SV.FMT_STR.PRINT_IMPROP_LENGTH
SV.FMT_STR.PRINT_PARAMS_WRONGNUM.FEW
SV.FMT_STR.PRINT_PARAMS_WRONGNUM.MANY
SV.FMT_STR.UNKWN_FORMAT.SCAN

 
LDRA tool suite9.5.6

41 S, 589 S

Partially implemented

Parasoft Insure++  Runtime
Polyspace Bug FinderR2016aFormat string specifiers and arguments mismatch

String specifiers do not match corresponding arguments

PRQA QA-C9.3

0179 (U)
0184 (U)
0185 (U)
0186 (U)
0190 (U)
0191 (U)
0192 (U)
0193 (U)
0194 (U)
0195 (U)
0196 (U)
0197 (U)
0198 (U)
0199 (U)
0200 (U)
0201 (U)
0206 (U)
0207
0208

Partially implemented

Related Vulnerabilities

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

Related Guidelines

ISO/IEC TR 24772:2013Type System [IHN]
Subprogram Signature Mismatch [OTR]
MISRA C:2012Rule 17.1 (required)

 


18 Comments

  1. The example here seems rather contrived. A mismatch between printf format specifications and arguments passed is a widely known problem and really does not have anything to do with the point of this rule.

    It seems to me that a better example would be one that intermixes arguments of clearly different widths (int with long long, float with double) so that a correcting ordered, but with incorrect type indicators, format string would result in extremely unexpected results.

    Lastly, it is unclear to me that alignment errors are possible. A variadic function call results in the "..." arguments being put through default promotions, regardless of their original widths (char and short -> int). In the end, the only two possible alignments are word or double-word (as the examples I gave above). On no architecture will a word boundary cause an alignment error. And only on rare architectures must double-word values be aligned on a double-word boundary (usually word boundaries are sufficient).

    All these details aside, my observation is that this example does not demonstrate your rule's title. 

    1. While the example seems contrived, on my copy of Visual C++ 2005 it compiles without warning on the highest warning level (and of course promptly crashes when ran due to the attempt to dereference the value 15 converted to an address). I think writing something off because it is a widely known problem is not the way to go about things.

      I agree that the previous NCCE/CS did not fully encompass what the recommendation was hoping to accomplish, but I'm not sure I understand how it does not demonstrate the rule's title--it displays a failure to understand the type issues of printf which leads to an integer being converted to a pointer which is dereferenced. I think your idea of displaying a width issue was a good idea and it has been added.

      As for the possibility of an alignment error, I've removed some references specifically mentioning this. However, since the scope of this wiki is the C standard, which does not define a specific concept of "words" or "double-words" and makes no guarantees about the effective dereference of something misaligned, I do not see anything wrong with mentioning this as a possibility, especially since, as you mention, it is a problem on some architectures.

  2. 100% of C programmers use printf(), but far less use variadic functions of their own creation, and I believe that making a separate printf-type page would make these rules a lot more approachable.

    The rules are essentially the same, of course, but removing the va_arg() business to a separate rule means that one can focus on conveying the alignment and promotion rules in a much more familiar context.

  3. long long a = 1L;
    char msg[] = "Default message";
    /* ... */
    printf("%lld %s", a, msg);
     
    sizeof(msg) will be 17 but not 128  (smile)

    long long a = 1L - Software Optimization Guide for AMD64 Processors

    1. I don't think I get it - naming an array size overrides the size implied by the initializer.

  4. I recall that Fortify SCA can also detect violations of this rule. Can someone double check and add to auto-detection section if appropriate?

  5. This is perhaps an issue specific to the macro NULL rather than to variadic functions but I haven't been able to find a rule that deals with the former.

    Another cause of undefined behavior is using the NULL macro as an argument to a variadic functions such as printf() or execl() where a pointer value is expected. For example, the following function calls will have undefined behavior when sizeof(NULL) != sizeof(void*) as may be the case in LP64 when NULL defined to be of type int:

    To ensure that the calls behave correctly the code must be written like so:

    1. The issue is specific to both NULL and variadic functions because

      • NULL may be defined as an int or a pointer
      • variadic functions do not convert between ints and pointers. (I think non-variadic functions will take NULL as an int or pointer as indicated by the function's appropriate argument type.)

      Anyway, I've added your issue to the rule as another NCCE/CS pair. Thanks!

      1. C99 does not define what happens if you pass NULL to a %s format; it expects the argument to be a valid char array, so I don't think this code can be a compliant code example, as it is undefined behavior (although it does alleviate the problem stated in DCL11-C).

        On a side note, most modern implementations handle this gracefully by printing "null" or some such, but we can't promote this while remaining compliant with C99.

        (BTW %p is C99, but C99 leaves as implementation-defined what actually gets printed.)

        1. Currently both lines of the last CCE pass NULL to a %s format.

          This may be a better example:

          1. I modified the compliant example to not pass NULL.

  6. I agree: neither NULL or (char*)0 is a valid argument for %s or any other conversion specification that expects a pointer to an object in memory (e.g., %n).

    1. NULL is perfectly fine for %p.

      1. %p does not expect a pointer to an object in memory, it expects a pointer to void, which is subtly different.  In the case of %s and %n, they expect a pointer to something specific that is then interpreted.  %p simply cares about the value of the pointer itself, not what the pointer is pointing to.

        To be clear, you are correct that NULL is perfectly fine for %p, just that %p is not covered by what Martin was referring to.

  7. I'm sorry, but I don't understand this NULL example. I know it's undefined (null pointer is not a string, and printing nothing could do anything), but the explanation just doesn't make sense. Yes, null pointer is not guaranteed to be ((void *) 0), but in this case it doesn't matter. Let's assume that we use a crazy platform where NULL is ((_Bool) 0) (by the way, C specification guarantes that any constant zero is null pointer), and the code is ran on it. After this strange boolean null is assigned to char *, the value is a pointer (pointer that would magically change sizes depending on whether it stores null pointer or not wouldn't make sense, would it?).

    I made a small code sample in order to show null pointer being boolean false. If you run it in compiler that understands null pointer is any constant zero (like Clang), you will notice that var has the same size as void *. The NULL is called NULLISH, because some compilers disallow redefining NULL.

    On my computer, this code returns 1 8 8, which makes sense. I believe the guideline should mention something else instead. I think that something like GTK+ variadic argument lists (real code) is a good idea for an example - in GTK, some functions expect list of strings that ends with null pointer. If the platform has null declared as integer, and size of pointers is different to size of integers, things break. For example, I propose following code sample as example, containing a big trap (if NULL is not declared as pointer, things are broken).

    Imagine that NULL is declared as boolean false (completely valid, even if it's silly). You would get random explosions that would be hard to debug just because _Bool is not const char *.

    1. The NULL example in its current form is broken.  string, as passed to printf() has a type of char * and so it will be passed using the appropriate size that printf() expects.  At some point, we should rewrite that example to be a bit more clear as to what the problem is, and the example you point out would be a reasonable demonstration of the problem.

      One other thing to note about using ((_Bool)0) are integer promotions that happen when passing an argument as part of a variable argument list.  You don't need anything nearly so contrived to demonstrate the problem.  On any system where sizeof(void *) != sizeof(int), you will run into this problem if NULL is an integer constant zero instead of a pointer constant zero.

      1. I'm considering on how to fix this currently-wrong NCCE(NULL).

        how about this idea?

        • change NCCE code to one line:  printf("%s %d\n", NULL, 1);
        • add a little more comment on passing NULL to "%s" specifier, which is undefined behavior
        • adding this NCCE to MSC15-C. Do not depend on undefined behavior

        BTW, I just learned that C++ defines NULL as integer, not pointer.

        (stll implementation-defined as 0 or 0L, but anyway, not a pointer!)

         

        1. The first two bullets sound great to me. I would also change the NCCE wording to mention that you cannot send a char * that is NULL either (as the current code does) because it would violate the %s constraint: "If no l length modifier is present, the argument shall be a pointer to the initial element of an array of character type." Either situation is undefined behavior, but the code you are proposing 1) fits the explanatory text already written, and 2) is more compelling.

          I would not bother with adding the NCCE to MSC15-C (a great many of our guidelines are due to undefined behavior).

          As for C++, the current recommended usage is to use nullptr instead of NULL because the former will be strongly typed to something sensible, while the latter is not type safe. You are correct that the macro NULL is an integral constant and not a pointer value in C++. (smile)