`MEM53-CPP`: False positive due to flow through `realloc`
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- devtools, testing-qa
Research direction
Start with the MEM53-CPP test cases and the taint-tracking configuration's isSource definition, then review the linked pull requests for the realloc flow change. Determine how the old AST-based library handles realloc and whether the affected test scenario is valid; done means the false positive is resolved without accepting an unsafe assumption about reallocating new-allocated memory.
Written by the indexing model from the issue text.
Description
Affected rules
MEM53-CPP
Description
In https://github.com/github/codeql/pull/14637 we added taint-flow through the indirection of the pointer passed to realloc to the indirection of the result. That is, flow through the following example:
int* p = ...;
*p = tainted_value;
int* q = (int*)realloc(p, 1024);
sink(*p);
this relies on the new taint-tracking library to distinguish between the result of realloc(...), and the result of what realloc(...) points to. Since the old AST-based taint-tracking library cannot do this this results in a FP in the testcases for MEM53-CPP (that we accepted on the next branch here: https://github.com/github/codeql-coding-standards/pull/419)
The query already tries to rule out realloc cases by excluding them in the definition of the taint-tracking configuration's isSource, but to get this query back to not reporting a FP here a barrier on realloc would have to be inserted.
As @jketema points out the affected test is actually really sketchy since there’s no guarantee that memory allocated with new can safely be realloc'ed. So maybe this scenario should be thought about more carefully by someone on your team.
- Dominant language
- CodeQL
- Stars
- 227
- Forks
- 82
- Avg merge
- 6d 7h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/codeql-coding-standards
-
false positive/false negative Stardard-MISRA-C++
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/codeql-coding-standards#1172 ·
-
Difficulty-Low false positive/false negative false-negative Impact-Low Standard-MISRA-C
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty-Medium false positive/false negative false-positive Impact-Medium Standard-CERT-C
Difficulty 4/5 3-5 days Newbie friendliness 48/100
github/codeql-coding-standards#1200 ·
-
`RULE-0-0-1`: "unreachable statement" false positives due to over-pruning of the control-flow graph Openfalse positive/false negative
Difficulty 4/5 3-5 days Newbie friendliness 48/100
github/codeql-coding-standards#1190 ·
-
false positive/false negative
Difficulty 3/5 1-2 days Newbie friendliness 65/100
github/codeql-coding-standards#1175 ·
All issues in github/codeql-coding-standards
Similar issues
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
learningequality/ricecooker#747 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
KhronosGroup/glTF-Blender-IO#2769 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100