Skip to content

C++: Add barriers to cpp/uncontrolled-allocation-size #5903

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
May 17, 2021

Conversation

MathiasVP
Copy link
Contributor

@MathiasVP MathiasVP commented May 14, 2021

(Part of https://github.com/github/codeql-c-team/issues/272.)

This PR adds two barriers to cpp/uncontrolled-allocation-size:

  • The first barrier (added in 5031b73) blocks flow out of arithmetic operations that we can prove won't overflow. This removes false positives in a couple of LGTM projects. When I compare 5031b73 to main we get:
Project Alerts with main Alerts with 5031b73
openssl/openssl 8 7
gpac/gpac 2 0
libretro/RetroArch 2 1
axiomatic-systems/Bento4 1 0
systemd/systemd 11 9
rizinorg/cutter 33 25
radareorg/radare2 29 22
haiku/haiku 14 12
kernel.org/pub/scm/network/iproute2/iproute2-next 3 1
Chia-Network/chiapos 1 0
ArtifexSoftware/ghostpdl 3 1
  • The second barrier (added in 2d0a561) blocks flow out of PointerDiffExpr. This is quite a common cause of false positives for this query. When I compare 5031b73 to 2d0a561) we get:
Project Alerts with 5031b73 Alerts with 2d0a561
vim/vim 1 0
openssl/openssl 7 0
git/git 1 0
lxc/lxc 1 0
alibaba/AliSQL 1 0
apache/trafficserver 2 1
stellar/stellar-core 3 0
systemd/systemd 9 6
nmap/nmap 1 0
cfengine/core 2 1
rizinorg/cutter 25 24
haiku/haiku 12 10
horms/openvswitch 1 0
trini/u-boot 1 0
FreeRADIUS/freeradius-server 1 0
ArtifexSoftware/ghostpdl 1 0

This change doesn't seem to affect SAMATE.

@MathiasVP MathiasVP added the C++ label May 14, 2021
@MathiasVP MathiasVP requested a review from a team as a code owner May 14, 2021 12:09
@@ -139,7 +139,7 @@ void more_bounded_tests() {

if (size > 0)
{
malloc(size * sizeof(int)); // BAD
malloc(size * sizeof(int)); // GOOD (overflow not possible)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a test with a long to keep testing size > 0 with an actual overflow?

Copy link
Contributor Author

@MathiasVP MathiasVP May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I've done this in 31091c6. Sorry about the horrible diff from that commit. All it's doing is move a few lines and add the correct BAD result to the .expected file.

Copy link
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

// Subtracting two pointers is either well-defined (and the result will likely be small), or
// terribly undefined and dangerous. Here, we assume that the programmer has ensured that the
// result is well-defined (i.e., the two pointers point to the same object), and thus the result
// will likely be small.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable. If the subtraction result is not well-defined, that should probably be handled by another query (which may or may-not already exist) rather than blaming a later malloc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. 👍 I've opened up https://github.com/github/codeql-c-team/issues/525 for this exact query idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants