Page History

...

Conversions between integers and pointers can have undesired consequences depending on the implementation.

According to the to the C Standard, subclause 6.3.2.3 3 [ISO/IEC 9899:20112024],

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

...

Do not convert a pointer type to an integer type if the result cannot be represented in the integer type. (see See undefined behavior 24.).

The mapping between pointers and integers must be consistent with the addressing structure of the execution environment. Issues may arise, for example, on architectures that have a segmented memory model.

...

Any valid pointer to void can be converted to intptr_t or uintptr_t and back with no change in value. (see See INT36-EX2.). The C Standard guarantees that a pointer to void may be converted to or from a pointer to any object type and back again and that the result must compare equal to the original pointer. Consequently, converting directly from a char * pointer to a uintptr_t, as in this compliant solution, is allowed on implementations that support the uintptr_t type.

...

The result of this assignment is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Compliant Solution

Adding an explicit cast may help the compiler convert the integer value into a valid pointer. A common technique is to assign the integer to a volatile-qualified object of type intptr_t or uintptr_t and then assign the integer value to the pointer:

...

...

Unfortunately this code cannot be made safe while strictly conforming to ISO C.

A particular platform (that is, hardware, operating system, compiler, and Standard C library) might guarantee that a memory address is correctly aligned for the pointer type, and actually contains a value for that type. A common practice is to use addresses that are known to point to hardware that provides valid values.

Exceptions

INT36-C-EX1: A null pointer can be converted to an integer; it takes on the value 0. Likewise, the integer value 0  The integer value 0 can be converted to a pointer; it becomes the null pointer.

...

Converting from pointer to integer or vice versa results in code that is not portable and may create unexpected pointers to invalid memory locations.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-758 and INT36-C

Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)

CWE-758 = Union( INT36-C, list) where list =

• Undefined behavior that results from anything other than integer <-> pointer conversion

CWE-704 and INT36-C

CWE-704 = Union( INT36-C, list) where list =

• Incorrect (?) typecast that is not between integers and pointers

CWE-587

...

and INT36-C

Intersection( CWE-587, INT36-C) =

• Setting a pointer to an integer value that is ill-defined (trap representation, improperly aligned, mis-typed, etc)

CWE-587 – INT36-C =

• Setting a pointer to a valid integer value (eg points to an object of the correct t ype)

INT36-C – CWE-587 =

• Illegal pointer-to-integer conversion

Intersection(INT36-C,CWE-466) =  ∅  

Intersection(INT36-C,CWE-466) =  ∅

An example explaining the above two equations follows:

static char x[3];

char* foo() {

  int x_int = (int) x; // x_int = 999 eg

  return x_int + 5; // returns 1004 , violates CWE 466

}

...

int y_int = foo(); // violates CWE-466

char* y = (char*) y_int; //  // well-defined but y may be invalid, violates INT36-C

char c = *y; // indeterminate value, out-of-bounds read, violates CWE-119

Bibliography

...

...

Image Modified Image Modified Image Modified