Skip to content
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

CPP: Support crement operations in CWE-190 #105

Merged
merged 8 commits into from
Aug 29, 2018
Merged

Conversation

geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Aug 24, 2018

Support crement operations in the CWE-190 queries. This fixes one of the 'regressions' we had when we changed from using Samate Juliet Test Suite version 1.2 to 1.3.

There's also a small improvement to the logic in ArithmeticWithExtremeValues.ql so that it understands the direction of the potential over/under-flow compared to the extreme value.

@geoffw0 geoffw0 added the C++ label Aug 24, 2018

| [User-controlled data in arithmetic expression] | More correct results | Crement operations are now understood as arithmetic operations in this query. |
| [Uncontrolled data in arithmetic expression] | More correct results | Crement operations are now understood as arithmetic operations in this query. |
| [Use of extreme values in arithmetic expression] | More correct results | Crement operations are now understood as arithmetic operations in this query. |
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think "Crement" is a standard enough term to be used in a change note. Better write it out as "increment/decrement".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

use = e.getAnOperand() and
exists(LocalScopeVariable v | use.getTarget() = v |
// overflow possible if large
(e instanceof AddExpr and not guardedLesser(e, varUse(v))) or
(e instanceof IncrementOperation and not guardedLesser(e, varUse(v)) and v.getType().getUnspecifiedType() instanceof IntegralType) or
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're supporting x + 1 and x++ then why not x += 1? Same for subtraction.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. FWIW I think some of these cases are naive, the right-hand-side of subtraction is ignored and most cases assume the other side of a binary arithmetic expression is (at least sometimes) positive. I'll make a JIRA ticket to look into improving this.

(isMaxValue(expr) and cause = "max value") or
(isMinValue(expr) and cause = "min value")
(isMaxValue(expr) and cause = "overflow") or
(isMinValue(expr) and cause = "underflow")
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the old strings match better what this predicate actually computes. Unless there's a good reason to change these strings, I suggest keeping them as they are and having both a string cause and a string effect in the query, matching them up in the or formulas. It looks strange now that cause and effect are conflated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@geoffw0 geoffw0 force-pushed the samate-crement branch 2 times, most recently from b6ccb9c to 0d63739 Compare August 28, 2018 15:45
Copy link
Contributor

@jbj jbj left a comment

Choose a reason for hiding this comment

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

Thanks. LGTM.

@jbj jbj merged commit 418a167 into github:master Aug 29, 2018
aibaars pushed a commit that referenced this pull request Oct 14, 2021
smowton pushed a commit to smowton/codeql that referenced this pull request Dec 6, 2021
erik-krogh pushed a commit to erik-krogh/ql that referenced this pull request Dec 15, 2021
New performance query: Transitive step in recursion.
erik-krogh pushed a commit to erik-krogh/ql that referenced this pull request Dec 15, 2021
…step

New performance query: Transitive step in recursion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants