Signed character data stored must be converted to an unsigned type before being assigned or converted to a larger signed type. Because compilers have the latitude to define char to have the same range, representation, and behavior as either signed char or unsigned char, this rule should be applied to both signed char and (plain) char characters.
This rule is only applicable in cases where the character data may contain values that can be interpreted as negative values. For example, if the char type is represented by a two's complement 8-bit value, any character value greater than +127 would be is interpreted as a negative value.
...
This non-compliant code example is taken from an actual vulnerability avulnerability in bash versions 1.14.6 and earlier that resulted in the release of CERT Advisory CA-1996-22. This vulnerability resulted from the sign extension of character data referenced by the string pointer in the yy_string_get() function in the parse.y module of the bash source code:
...
In this compliant solution, the result of the expression *string++ is cast to (unsigned char) before assigning it assignment to the int variable c.
| Code Block | ||
|---|---|---|
| ||
static int yy_string_get() {
register char *string;
register int c;
string = bash_input.location.string;
c = EOF;
/* If the string doesn't exist, or is empty, EOF found. */
if (string && *string) {
c = (unsigned char)*string++; /* cast to unsigned type */
bash_input.location.string = string;
}
return (c);
}
|
...