Skip to content

Commit b5cf930

Browse files
committed
Merge branch 'Contracts6' of https://github.com/mbaluda-org/codeql-coding-standards into Contracts6
2 parents 541515d + 22b7bef commit b5cf930

File tree

81 files changed

+3745
-126
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

81 files changed

+3745
-126
lines changed

.vscode/tasks.json

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -236,6 +236,7 @@
236236
"Lambdas",
237237
"Language1",
238238
"Language2",
239+
"Language3",
239240
"Literals",
240241
"Loops",
241242
"Macros",

c/cert/src/rules/ERR32-C/DoNotRelyOnIndeterminateValuesOfErrno.ql

Lines changed: 4 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -13,21 +13,9 @@
1313
import cpp
1414
import codingstandards.c.cert
1515
import codingstandards.c.Errno
16+
import codingstandards.c.Signal
1617
import semmle.code.cpp.controlflow.Guards
1718

18-
/**
19-
* A call to function `signal`
20-
*/
21-
class SignalCall extends FunctionCall {
22-
SignalCall() { this.getTarget().hasGlobalName("signal") }
23-
}
24-
25-
/**
26-
* A call to `abort` or `_Exit`
27-
*/
28-
class AbortCall extends FunctionCall {
29-
AbortCall() { this.getTarget().hasGlobalName(["abort", "_Exit"]) }
30-
}
3119

3220
/**
3321
* A check on `signal` call return value
@@ -47,22 +35,16 @@ class SignalCheckOperation extends EqualityOperation, GuardCondition {
4735
)
4836
}
4937

50-
BasicBlock getCheckedSuccessor() {
51-
result != errorSuccessor and result = this.getASuccessor()
52-
}
38+
BasicBlock getCheckedSuccessor() { result != errorSuccessor and result = this.getASuccessor() }
5339

5440
BasicBlock getErrorSuccessor() { result = errorSuccessor }
5541
}
5642

5743
/**
5844
* Models signal handlers that call signal() and return
5945
*/
60-
class SignalCallingHandler extends Function {
61-
SignalCall registration;
62-
46+
class SignalCallingHandler extends SignalHandler {
6347
SignalCallingHandler() {
64-
// is a signal handler
65-
this = registration.getArgument(1).(FunctionAccess).getTarget() and
6648
// calls signal() on the handled signal
6749
exists(SignalCall sCall |
6850
sCall.getEnclosingFunction() = this and
@@ -75,8 +57,6 @@ class SignalCallingHandler extends Function {
7557
)
7658
)
7759
}
78-
79-
SignalCall getCall() { result = registration }
8060
}
8161

8262
/**
@@ -100,7 +80,7 @@ where
10080
not isExcluded(errno, Contracts5Package::doNotRelyOnIndeterminateValuesOfErrnoQuery()) and
10181
exists(SignalCallingHandler handler |
10282
// errno read after the handler returns
103-
handler.getCall() = signal
83+
handler.getRegistration() = signal
10484
or
10585
// errno read inside the handler
10686
signal.getEnclosingFunction() = handler

c/cert/src/rules/FLP32-C/UncheckedRangeDomainPoleErrors.md

Lines changed: 352 additions & 0 deletions
Large diffs are not rendered by default.
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
/**
2+
* @id c/cert/unchecked-range-domain-pole-errors
3+
* @name FLP32-C: Prevent or detect domain and range errors in math functions
4+
* @description Range, domain or pole errors in math functions may return unexpected values, trigger
5+
* floating-point exceptions or set unexpected error modes.
6+
* @kind problem
7+
* @precision high
8+
* @problem.severity error
9+
* @tags external/cert/id/flp32-c
10+
* correctness
11+
* external/cert/obligation/rule
12+
*/
13+
14+
import cpp
15+
import codingstandards.c.cert
16+
import codingstandards.cpp.rules.uncheckedrangedomainpoleerrors.UncheckedRangeDomainPoleErrors
17+
18+
class UncheckedRangeDomainPoleErrorsQuery extends UncheckedRangeDomainPoleErrorsSharedQuery {
19+
UncheckedRangeDomainPoleErrorsQuery() {
20+
this = FloatingTypesPackage::uncheckedRangeDomainPoleErrorsQuery()
21+
}
22+
}
Lines changed: 181 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
# FLP34-C: Ensure that floating-point conversions are within range of the new type
2+
3+
This query implements the CERT-C rule FLP34-C:
4+
5+
> Ensure that floating-point conversions are within range of the new type
6+
7+
8+
## Description
9+
10+
If a floating-point value is to be converted to a floating-point value of a smaller range and precision or to an integer type, or if an integer type is to be converted to a floating-point type, the value must be representable in the destination type.
11+
12+
The C Standard, 6.3.1.4, paragraph 1 \[[ISO/IEC 9899:2011](https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography#AA.Bibliography-ISO-IEC9899-2011)\], says,
13+
14+
> When a finite value of real floating type is converted to an integer type other than `_Bool`, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is [undefined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior).
15+
16+
17+
Paragraph 2 of the same subclause says,
18+
19+
> When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an [implementation-defined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation-definedbehavior) manner. If the value being converted is outside the range of values that can be represented, the behavior is [undefined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior).
20+
21+
22+
And subclause 6.3.1.5, paragraph 1, says,
23+
24+
> When a value of real floating type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an [implementation-defined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation-definedbehavior) manner. If the value being converted is outside the range of values that can be represented, the behavior is [undefined](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior).
25+
26+
27+
See [undefined behaviors 17](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_17) and [18](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_18).
28+
29+
This rule does not apply to demotions of floating-point types on [implementations](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation) that support signed infinity, such as IEEE 754, as all values are within range.
30+
31+
## Noncompliant Code Example (float to int)
32+
33+
This noncompliant code example leads to undefined behavior if the integral part of `f_a` cannot be represented as an integer:
34+
35+
```cpp
36+
void func(float f_a) {
37+
int i_a;
38+
39+
/* Undefined if the integral part of f_a cannot be represented. */
40+
i_a = f_a;
41+
}
42+
```
43+
44+
## Compliant Solution (float to int)
45+
46+
This compliant solution tests to ensure that the `float` value will fit within the `int` variable before performing the assignment.
47+
48+
```cpp
49+
#include <float.h>
50+
#include <limits.h>
51+
#include <math.h>
52+
#include <stddef.h>
53+
#include <stdint.h>
54+
55+
extern size_t popcount(uintmax_t); /* See INT35-C */
56+
#define PRECISION(umax_value) popcount(umax_value)
57+
58+
void func(float f_a) {
59+
int i_a;
60+
61+
if (isnan(f_a) ||
62+
PRECISION(INT_MAX) < log2f(fabsf(f_a)) ||
63+
(f_a != 0.0F && fabsf(f_a) < FLT_MIN)) {
64+
/* Handle error */
65+
} else {
66+
i_a = f_a;
67+
}
68+
}
69+
70+
```
71+
72+
## Noncompliant Code Example (Narrowing Conversion)
73+
74+
This noncompliant code example attempts to perform conversions that may result in truncating values outside the range of the destination types:
75+
76+
```cpp
77+
void func(double d_a, long double big_d) {
78+
double d_b = (float)big_d;
79+
float f_a = (float)d_a;
80+
float f_b = (float)big_d;
81+
}
82+
83+
```
84+
As a result of these conversions, it is possible that `d_a` is outside the range of values that can be represented by a float or that `big_d` is outside the range of values that can be represented as either a `float` or a `double`. If this is the case, the result is undefined on implementations that do not support Annex F, "IEC 60559 Floating-Point Arithmetic."
85+
86+
## Compliant Solution (Narrowing Conversion)
87+
88+
This compliant solution checks whether the values to be stored can be represented in the new type:
89+
90+
```cpp
91+
#include <float.h>
92+
#include <math.h>
93+
94+
void func(double d_a, long double big_d) {
95+
double d_b;
96+
float f_a;
97+
float f_b;
98+
99+
if (d_a != 0.0 &&
100+
(isnan(d_a) ||
101+
isgreater(fabs(d_a), FLT_MAX) ||
102+
isless(fabs(d_a), FLT_MIN))) {
103+
/* Handle error */
104+
} else {
105+
f_a = (float)d_a;
106+
}
107+
if (big_d != 0.0 &&
108+
(isnan(big_d) ||
109+
isgreater(fabs(big_d), FLT_MAX) ||
110+
isless(fabs(big_d), FLT_MIN))) {
111+
/* Handle error */
112+
} else {
113+
f_b = (float)big_d;
114+
}
115+
if (big_d != 0.0 &&
116+
(isnan(big_d) ||
117+
isgreater(fabs(big_d), DBL_MAX) ||
118+
isless(fabs(big_d), DBL_MIN))) {
119+
/* Handle error */
120+
} else {
121+
d_b = (double)big_d;
122+
}
123+
}
124+
125+
```
126+
127+
## Risk Assessment
128+
129+
Converting a floating-point value to a floating-point value of a smaller range and precision or to an integer type, or converting an integer type to a floating-point type, can result in a value that is not representable in the destination type and is undefined behavior on implementations that do not support Annex F.
130+
131+
<table> <tbody> <tr> <th> Rule </th> <th> Severity </th> <th> Likelihood </th> <th> Remediation Cost </th> <th> Priority </th> <th> Level </th> </tr> <tr> <td> FLP34-C </td> <td> Low </td> <td> Unlikely </td> <td> Low </td> <td> <strong>P3</strong> </td> <td> <strong>L3</strong> </td> </tr> </tbody> </table>
132+
133+
134+
## Automated Detection
135+
136+
<table> <tbody> <tr> <th> Tool </th> <th> Version </th> <th> Checker </th> <th> Description </th> </tr> <tr> <td> <a> Astrée </a> </td> <td> 22.04 </td> <td> </td> <td> Supported Astrée reports all potential overflows resulting from floating-point conversions. </td> </tr> <tr> <td> <a> Compass/ROSE </a> </td> <td> </td> <td> </td> <td> Can detect some violations of this rule. However, it does not flag implicit casts, only explicit ones </td> </tr> <tr> <td> <a> CodeSonar </a> </td> <td> 7.2p0 </td> <td> <strong>LANG.TYPE.IAT</strong> </td> <td> Inappropriate Assignment Type </td> </tr> <tr> <td> <a> Coverity </a> </td> <td> 2017.07 </td> <td> <strong>MISRA_CAST (needs verification)</strong> </td> <td> Can detect instances where implicit float conversion is involved: implicitly converting a complex expression with integer type to floating type, implicitly converting a double expression to narrower float type (may lose precision), implicitly converting a complex expression from <code>float</code> to <code>double</code> , implicitly converting from <code>float</code> to <code>double</code> in a function argument, and so on </td> </tr> <tr> <td> <a> Helix QAC </a> </td> <td> 2022.4 </td> <td> <strong>C4450, C4451, C4452, C4453, C4454, C4462, C4465</strong> <strong>C++3011</strong> </td> <td> </td> </tr> <tr> <td> <a> Klocwork </a> </td> <td> 2022.4 </td> <td> <strong>MISRA.CAST.FLOAT.WIDER</strong> <strong>MISRA.CAST.FLOAT.INT</strong> <strong>MISRA.CAST.INT_FLOAT</strong> <strong>MISRA.CONV.FLOAT</strong> </td> <td> </td> </tr> <tr> <td> <a> LDRA tool suite </a> </td> <td> 9.7.1 </td> <td> <strong>435 S, 93 S</strong> </td> <td> Partially implemented </td> </tr> <tr> <td> <a> Parasoft C/C++test </a> </td> <td> 2022.2 </td> <td> <strong>CERT_C-FLP34-aCERT_C-FLP34-b</strong> </td> <td> Avoid implicit conversions from wider to narrower floating type Avoid implicit conversions of floating point numbers from wider to narrower floating type </td> </tr> <tr> <td> <a> PC-lint Plus </a> </td> <td> 1.4 </td> <td> <strong>735, 736,915, 922,9118, 9227</strong> </td> <td> Partially supported </td> </tr> <tr> <td> <a> Polyspace Bug Finder </a> </td> <td> R2022b </td> <td> <a> CERT C: Rule FLP34-C </a> </td> <td> Checks for float conversion overflow (rule partially covered) </td> </tr> <tr> <td> <a> PRQA QA-C </a> </td> <td> 9.7 </td> <td> <strong>4450, 4451, 4452, 4453,4454, </strong> <strong>4462, </strong> <strong>4465</strong> </td> <td> Partially implemented </td> </tr> <tr> <td> <a> PRQA QA-C++ </a> </td> <td> 4.4 </td> <td> <strong>3011 </strong> </td> <td> </td> </tr> <tr> <td> <a> PVS-Studio </a> </td> <td> 7.23 </td> <td> <strong>V615<a></a></strong> , <strong>V2003<a></a></strong> , <strong><a>V2004</a></strong> </td> <td> </td> </tr> <tr> <td> <a> TrustInSoft Analyzer </a> </td> <td> 1.38 </td> <td> <strong>float_to_int</strong> </td> <td> Exhaustively verified (see <a> one compliant and one non-compliant example </a> ). </td> </tr> </tbody> </table>
137+
138+
139+
## Related Vulnerabilities
140+
141+
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+FLP34-C).
142+
143+
## Related Guidelines
144+
145+
[Key here](https://wiki.sei.cmu.edu/confluence/display/c/How+this+Coding+Standard+is+Organized#HowthisCodingStandardisOrganized-RelatedGuidelines) (explains table format and definitions)
146+
147+
<table> <tbody> <tr> <th> Taxonomy </th> <th> Taxonomy item </th> <th> Relationship </th> </tr> <tr> <td> <a> CERT Oracle Secure Coding Standard for Java </a> </td> <td> <a> NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data </a> </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> ISO/IEC TR 24772:2013 </a> </td> <td> Numeric Conversion Errors \[FLC\] </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> CWE 2.11 </a> </td> <td> <a> CWE-681 </a> , Incorrect Conversion between Numeric Types </td> <td> 2017-06-29: CERT: Rule subset of CWE </td> </tr> <tr> <td> <a> CWE 2.11 </a> </td> <td> <a> CWE-197 </a> </td> <td> 2017-06-14: CERT: Rule subset of CWE </td> </tr> </tbody> </table>
148+
149+
150+
## CERT-CWE Mapping Notes
151+
152+
[Key here](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152408#HowthisCodingStandardisOrganized-CERT-CWEMappingNotes) for mapping notes
153+
154+
**CWE-197 and FLP34-C**
155+
156+
Independent( FLP34-C, INT31-C) FIO34-C = Subset( INT31-C)
157+
158+
CWE-197 = Union( FLP34-C, INT31-C)
159+
160+
**CWE-195 and FLP34-C**
161+
162+
Intersection( CWE-195, FLP34-C) = Ø
163+
164+
Both conditions involve type conversion. However, CWE-195 explicitly focuses on conversions between unsigned vs signed types, whereas FLP34-C focuses on floating-point arithmetic.
165+
166+
**CWE-681 and FLP34-C**
167+
168+
CWE-681 = Union( FLP34-C, INT31-C)
169+
170+
## Bibliography
171+
172+
<table> <tbody> <tr> <td> \[ <a> IEEE 754 2006 </a> \] </td> <td> </td> </tr> <tr> <td> \[ <a> ISO/IEC 9899:2011 </a> \] </td> <td> Subclause 6.3.1.4, "Real Floating and Integer" Subclause 6.3.1.5, "Real Floating Types" </td> </tr> </tbody> </table>
173+
174+
175+
## Implementation notes
176+
177+
None
178+
179+
## References
180+
181+
* CERT-C: [FLP34-C: Ensure that floating-point conversions are within range of the new type](https://wiki.sei.cmu.edu/confluence/display/c)
Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
/**
2+
* @id c/cert/unchecked-floating-point-conversion
3+
* @name FLP34-C: Ensure that floating-point conversions are within range of the new type
4+
* @description Conversions of out-of-range floating-point values to integral types can lead to
5+
* undefined behavior.
6+
* @kind problem
7+
* @precision high
8+
* @problem.severity error
9+
* @tags external/cert/id/flp34-c
10+
* correctness
11+
* external/cert/obligation/rule
12+
*/
13+
14+
import cpp
15+
import codingstandards.c.cert
16+
import semmle.code.cpp.rangeanalysis.SimpleRangeAnalysis
17+
import semmle.code.cpp.controlflow.Guards
18+
19+
/*
20+
* There are three cases to consider under this rule:
21+
* 1) Float-to-int
22+
* 2) Narrowing float-to-float conversions
23+
* 3) Int-to-float
24+
*
25+
* The first results in undefined behaviour if the float is outside the range of the int, and is
26+
* the topic of this query.
27+
*
28+
* The second two cases only cause undefined behaviour if the floating point format does not
29+
* support -inf/+inf. This information is not definitively present in the CodeQL database. The
30+
* macro INFINITY in principle differs in the two cases, but we are unable to distinguish one case
31+
* from the other.
32+
*
33+
* (2) and (3) do not appear to be problems in practice on the hardware targets and compilers we
34+
* support, because they all provide +inf and -inf unconditionally.
35+
*/
36+
37+
/**
38+
* A function whose name is suggestive that it counts the number of bits set.
39+
*/
40+
class PopCount extends Function {
41+
PopCount() { this.getName().toLowerCase().matches("%popc%nt%") }
42+
}
43+
44+
/**
45+
* A macro which is suggestive that it is used to determine the precision of an integer.
46+
*/
47+
class PrecisionMacro extends Macro {
48+
PrecisionMacro() { this.getName().toLowerCase().matches("precision") }
49+
}
50+
51+
bindingset[value]
52+
predicate withinIntegralRange(IntegralType typ, float value) {
53+
exists(float lb, float ub, float limit |
54+
limit = 2.pow(8 * typ.getSize()) and
55+
(
56+
if typ.isUnsigned()
57+
then (
58+
lb = 0 and ub = limit - 1
59+
) else (
60+
lb = -limit / 2 and
61+
ub = (limit / 2) - 1
62+
)
63+
) and
64+
value >= lb and
65+
value <= ub
66+
)
67+
}
68+
69+
from FloatingPointToIntegralConversion c, ArithmeticType underlyingTypeAfter
70+
where
71+
not isExcluded(c, FloatingTypesPackage::uncheckedFloatingPointConversionQuery()) and
72+
underlyingTypeAfter = c.getUnderlyingType() and
73+
not (
74+
// Either the upper or lower bound of the expression is outside the range of the new type
75+
withinIntegralRange(underlyingTypeAfter, [upperBound(c.getExpr()), lowerBound(c.getExpr())])
76+
or
77+
// Heuristic - is there are guard the abs value of the float can fit in the precision of an int?
78+
exists(GuardCondition gc, FunctionCall log2, FunctionCall fabs, Expr precision |
79+
// gc.controls(c, false) and
80+
log2.getTarget().hasGlobalOrStdName("log2" + ["", "l", "f"]) and
81+
fabs.getTarget().hasGlobalOrStdName("fabs" + ["", "l", "f"]) and
82+
log2.getArgument(0) = fabs and
83+
// Precision is either a macro expansion or function call
84+
(
85+
precision.(FunctionCall).getTarget() instanceof PopCount
86+
or
87+
precision = any(PrecisionMacro pm).getAnInvocation().getExpr()
88+
) and
89+
gc.ensuresLt(precision, log2, 0, c.getExpr().getBasicBlock(), false)
90+
)
91+
)
92+
select c, "Conversion of float to integer without appropriate guards avoiding undefined behavior."

0 commit comments

Comments
 (0)