# V1010. Unchecked tainted data is used in expression.

The analyzer has detected the use of external data without preliminary check. Putting too much trust in such data may have various negative implications, including security issues.

At present, the V1010 diagnostic detects the following error patterns:

- Unchecked tainted data is used in the argument that is expected to contain verified data.
- Corrupting a pointer by changing its value using unchecked tainted data.

Note. Starting with the 7.32 version, users can mark functions as sources and sinks of tainted data. You can see examples of annotations here.

Each pattern is discussed in detail below.

Example of suspicious code using unchecked tainted data as an argument to a function:

    char buf[1024];
    char username [256];
    ....
    if (scanf("%255s", username) == 1)
    {
      if (snprintf(buf, sizeof(buf) - 1, commandFormat, username) > 0)
      {
        int exitCode = system(buf); // <=
        ....
      }
      ....
    }

This code is vulnerable as the program passes the user input to the command-line interpreter without checking it. For example, entering "&cmd" in Windows could give the user access to the command-line interpreter.

The correct version of the code must execute an additional check of the data read:

    if (IsValid(username))
    {
      if (snprintf(buf, sizeof(buf) - 1, commandFormat, username) > 0)
      {
        int exitCode = system(buf);
        ....
      }
      ....
    }
    else
    {
      printf("Invalid username: %s", username);
      ....
    }

Example of suspicious code with pointer corruption:

    size_t offset = 0;
    int *pArr = arr;
    ....
    if (scanf("%zu", &offset) == 1)
    {
      pArr += offset; // <=
      ....
      DoSomething(pArr);
    }

In this example, the value of the 'pArr' pointer becomes corrupt because adding the unchecked tainted value 'offset' may cause the pointer to start referencing beyond the array bounds. This poses a risk of corrupting some data (which will be referred to by 'pArr') with unpredictable consequences.

The correct version of the code checks the validity of the offset:

    if (offset <= allowableOffset)
    {
      pArr += offset;
      ....
      DoSomething(pArr);
    }

This diagnostic is classified as:

CWE-134 CWE-138 CWE-20 CWE-78

You can look at examples of errors detected by the V1010 diagnostic.