You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: c/cert/src/rules/INT36-C/ConvertingAPointerToIntegerOrIntegerToPointer.md
+200-2Lines changed: 200 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,207 @@ This query implements the CERT-C rule INT36-C:
5
5
> Converting a pointer to integer or integer to pointer
6
6
7
7
8
-
## CERT
8
+
## Description
9
+
10
+
Although programmers often use integers and pointers interchangeably in C, pointer-to-integer and integer-to-pointer conversions are [implementation-defined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation-definedbehavior).
11
+
12
+
Conversions between integers and pointers can have undesired consequences depending on the [implementation](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation). According to the C Standard, subclause 6.3.2.3 \[[ISO/IEC 9899:2011](https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography#AA.Bibliography-ISO-IEC9899-2011)\],
13
+
14
+
> 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.
15
+
16
+
17
+
> Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.
18
+
19
+
20
+
Do not convert an integer type to a pointer type if the resulting pointer is incorrectly aligned, does not point to an entity of the referenced type, or is a [trap representation](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-traprepresentation).
21
+
22
+
Do not convert a pointer type to an integer type if the result cannot be represented in the integer type. (See [undefined behavior 24](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_24).)
23
+
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.
25
+
26
+
## Noncompliant Code Example
27
+
28
+
The size of a pointer can be greater than the size of an integer, such as in an implementation where pointers are 64 bits and unsigned integers are 32 bits. This code example is noncompliant on such implementations because the result of converting the 64-bit `ptr` cannot be represented in the 32-bit integer type:
29
+
30
+
```cpp
31
+
voidf(void) {
32
+
char *ptr;
33
+
/* ... */
34
+
unsigned int number = (unsigned int)ptr;
35
+
/* ... */
36
+
}
37
+
38
+
```
39
+
40
+
## Compliant Solution
41
+
42
+
Any valid pointer to `void` can be converted to `intptr_t` or `uintptr_t` and back with no change in value. (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.
43
+
44
+
```cpp
45
+
#include <stdint.h>
46
+
47
+
void f(void) {
48
+
char *ptr;
49
+
/* ... */
50
+
uintptr_t number = (uintptr_t)ptr;
51
+
/* ... */
52
+
}
53
+
54
+
```
55
+
56
+
## Noncompliant Code Example
57
+
58
+
In this noncompliant code example, the pointer `ptr` is converted to an integer value. The high-order 9 bits of the number are used to hold a flag value, and the result is converted back into a pointer. This example is noncompliant on an implementation where pointers are 64 bits and unsigned integers are 32 bits because the result of converting the 64-bit `ptr` cannot be represented in the 32-bit integer type.
59
+
60
+
```cpp
61
+
voidfunc(unsigned int flag) {
62
+
char *ptr;
63
+
/* ... */
64
+
unsigned int number = (unsigned int)ptr;
65
+
number = (number & 0x7fffff) | (flag << 23);
66
+
ptr = (char *)number;
67
+
}
68
+
69
+
```
70
+
A similar scheme was used in early versions of Emacs, limiting its portability and preventing the ability to edit files larger than 8MB.
71
+
72
+
## Compliant Solution
73
+
74
+
This compliant solution uses a `struct` to provide storage for both the pointer and the flag value. This solution is portable to machines of different word sizes, both smaller and larger than 32 bits, working even when pointers cannot be represented in any integer type.
75
+
76
+
```cpp
77
+
struct ptrflag {
78
+
char *pointer;
79
+
unsigned int flag : 9;
80
+
} ptrflag;
81
+
82
+
void func(unsigned int flag) {
83
+
char *ptr;
84
+
/* ... */
85
+
ptrflag.pointer = ptr;
86
+
ptrflag.flag = flag;
87
+
}
88
+
89
+
```
90
+
91
+
## Noncompliant Code Example
92
+
93
+
It is sometimes necessary to access memory at a specific location, requiring a literal integer to pointer conversion. In this noncompliant code, a pointer is set directly to an integer constant, where it is unknown whether the result will be as intended:
94
+
95
+
```cpp
96
+
unsignedint *g(void) {
97
+
unsigned int *ptr = 0xdeadbeef;
98
+
/* ... */
99
+
return ptr;
100
+
}
101
+
```
102
+
The result of this assignment is [implementation-defined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation-definedbehavior), might not be correctly aligned, might not point to an entity of the referenced type, and might be a [trap representation](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-traprepresentation).
103
+
104
+
## Compliant Solution
105
+
106
+
Unfortunately this code cannot be made safe while strictly conforming to ISO C.
107
+
108
+
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.
109
+
110
+
## Exceptions
111
+
112
+
**INT36-C-EX1:** The integer value 0 can be converted to a pointer; it becomes the null pointer.
113
+
114
+
**INT36-C-EX2:** Any valid pointer to `void` can be converted to `intptr_t` or `uintptr_t` or their underlying types and back again with no change in value. Use of underlying types instead of `intptr_t` or `uintptr_t` is discouraged, however, because it limits portability.
115
+
116
+
```cpp
117
+
#include <assert.h>
118
+
#include <stdint.h>
119
+
120
+
void h(void) {
121
+
intptr_t i = (intptr_t)(void *)&i;
122
+
uintptr_t j = (uintptr_t)(void *)&j;
123
+
124
+
void *ip = (void *)i;
125
+
void *jp = (void *)j;
126
+
127
+
assert(ip == &i);
128
+
assert(jp == &j);
129
+
}
130
+
131
+
```
132
+
133
+
## Risk Assessment
134
+
135
+
Converting from pointer to integer or vice versa results in code that is not portable and may create unexpected pointers to invalid memory locations.
Search for [vulnerabilities](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-vulnerability) resulting from the violation of this rule on the [CERT website](https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+INT36-C).
148
+
149
+
## Related Guidelines
150
+
151
+
[Key here](https://wiki.sei.cmu.edu/confluence/display/c/How+this+Coding+Standard+is+Organized#HowthisCodingStandardisOrganized-RelatedGuidelines) (explains table format and definitions)
152
+
153
+
<table> <tbody> <tr> <th> Taxonomy </th> <th> Taxonomy item </th> <th> Relationship </th> </tr> <tr> <td> <a> CERT C </a> </td> <td> <a> INT11-CPP. Take care when converting from pointer to integer or integer to pointer </a> </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> ISO/IEC TR 24772:2013 </a> </td> <td> Pointer Casting and Pointer Type Changes \[HFC\] </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> ISO/IEC TS 17961:2013 </a> </td> <td> Converting a pointer to integer or integer to pointer \[intptrconv\] </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> CWE 2.11 </a> </td> <td> <a> CWE-587 </a> , Assignment of a Fixed Address to a Pointer </td> <td> 2017-07-07: CERT: Partial overlap </td> </tr> <tr> <td> <a> CWE 2.11 </a> </td> <td> <a> CWE-704 </a> </td> <td> 2017-06-14: CERT: Rule subset of CWE </td> </tr> <tr> <td> <a> CWE 2.11 </a> </td> <td> <a> CWE-758 </a> </td> <td> 2017-07-07: CERT: Rule subset of CWE </td> </tr> <tr> <td> <a> CWE 3.1 </a> </td> <td> <a> CWE-119 </a> , Improper Restriction of Operations within the Bounds of a Memory Buffer </td> <td> 2018-10-19:CERT:None </td> </tr> <tr> <td> <a> CWE 3.1 </a> </td> <td> <a> CWE-466 </a> , Return of Pointer Value Outside of Expected Range </td> <td> 2018-10-19:CERT:None </td> </tr> </tbody> </table>
154
+
155
+
156
+
## CERT-CWE Mapping Notes
157
+
158
+
[Key here](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152408#HowthisCodingStandardisOrganized-CERT-CWEMappingNotes) for mapping notes
0 commit comments