The formatted output functions (fprintf() and related functions) convert, format, and print their arguments under control of a format string, defined as follows by the C Standard, 7.21.6.1, paragraph 3 [ISO/IEC 9899:2011]:

The format shall be a multibyte character sequence, beginning and ending in its initial shift state. The format is composed of zero or more directives: ordinary multibyte characters (not %), which are copied unchanged to the output stream; and conversion specifications, each of which results in fetching zero or more subsequent arguments, converting them, if applicable, according to the corresponding conversion specifier, and then writing the result to the output stream.

Each conversion specification is introduced by the % character followed (in order) by

• Zero or more flags (in any order), which modify the meaning of the conversion specification
• An optional minimum field width
• An optional precision that gives the minimum number of digits to appear for certain conversion specifiers
• An optional length modifier that specifies the size of the argument
• A conversion specifier character that indicates the type of conversion to be applied

Common mistakes in creating format strings include

• Providing insufficient arguments for the format string
• Using invalid conversion specifiers
• Using a flag character that is incompatible with the conversion specifier
• Using a length modifier that is incompatible with the conversion specifier
• Mismatching the argument type and conversion specifier
• Using an argument of type other than int for width or precision

The following table summarizes the compliance of various conversion specifications.  The first column contains a conversion specifier character (or characters).  The next four columns consider the combination of the specifier character(s) with the various flags (the apostrophe ['], -, +, the space character, and #).  The next eight columns consider the combination of the specifier character(s) with the various length modifiers (h, hh, l, ll, j, z, t, and L).  Here, valid combinations are marked with a type name; arguments matched with the conversion specification will be interpreted as that type.  For example, an argument matched with the specifier %hd will be interpreted as a short, so short appears in the cell where d and h intersect.  The last column denotes the expected type of arguments matched with the original specifier character(s).  Throughout the table, valid and meaningful combinations are marked by the  symbol (save for the length modifier columns, as described above).  Valid combinations that have no effect are labeled N/E.  Using a combination marked by the symbol, using a specification not represented in the table, or using an argument of an unexpected type may result in undefined behavior. See undefined behaviors 153, 155, 157, 158, 161, and 162 in Annex J of the C Standard. 

Legend:

• SPACE—the space (" ") character
• N/E—no effect
• NTBS—char* argument pointing to a null-terminated byte string
• NTWS—wchar_t* argument pointing to a null-terminated wide character string
• XSI—ISO/IEC 9945-2003 XSI extension

The format input functions (fscanf() and related functions) use similarly-specified format strings and impose similar restrictions on their format strings and arguments.

Do not supply an unknown or invalid conversion specification or an invalid combination of flag character, precision, length modifier, conversion specifier; to a formatted IO function. Likewise, do not provide a number or type of arguments that do not match the conversion specifiers in the format string.

Format strings are usually string literals specified at the call site, but they need not be. They should, however, not contain unsanitized data; see FIO30-C. Exclude user input from format strings for more information.

Noncompliant Code Example

Mismatches between arguments and conversion specifications may result in undefined behavior.  Many compilers can diagnose type mismatches in formatted output function invocations.  In the following noncompliant code example, the error_type argument to printf() is incorrectly matched with the %s specifier, rather than with the %d specifier. Likewise, the error_msg argument is incorrectly matched with the %d specifier instead of the %s specifier.  One possible result of this invocation is that printf() will interpret the error_type argument as a pointer, and try to read a string from the address that error_type contains. This is likely to result in an access violation.

#include <stdio.h>
 
void func(void) {
  const char *error_msg = "Resource not available to user.";
  int error_type = 3;
  /* ... */
  printf("Error (type %s): %d\n", error_type, error_msg);
  /* ... */
}

Compliant Solution

This compliant solution ensures that the format arguments match their respective format specifications:

#include <stdio.h>
 
void func(void) {
  const char *error_msg = "Resource not available to user.";
  int error_type = 3;
  /* ... */
  printf("Error (type %d): %s\n", error_type, error_msg);

  /* ... */
}

Risk Assessment

In most cases, incorrectly specified format strings will result in abnormal program termination. However, in some cases they can be used to corrupt memory in manners controllable by an attacker.

Automated Detection

Tool	Version	Checker	Description
GCC			Can detect violations of this recommendation when the -Wformat flag is used
Klocwork		SV.FMT_STR
LDRA tool suite		486 S 589 S	Fully implemented
PRQA QA-C		0179 (U) 0180 (C99) 0184 (U) 0185 (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) 0202 (I) 0206 (U)	Partially implemented

Related Vulnerabilities

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

Related Guidelines

Bibliography