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: Add query for CWE-691 Insufficient Control Flow Management After Refactoring The Code #5601

Merged
merged 11 commits into from Apr 21, 2021
Merged

CPP: Add query for CWE-691 Insufficient Control Flow Management After Refactoring The Code #5601

merged 11 commits into from Apr 21, 2021

Conversation

ihsinme
Copy link
Contributor

@ihsinme ihsinme commented Apr 6, 2021

Good day.
This PR looks for situations of losses after refactoring. Two situations are considered. The first forgotten empty while after the loop. And arephmetics in comparison.
the first case is quite rare.
and can lead to an impact on the availability of resources. (hang)
but the second is widely represented.
and is more often influenced by the logic of the program
I tried to remove the false detection as much as possible.

Information about found and accepted fix in the project:
axboe/fio#1194

@MathiasVP
Copy link
Contributor

@MathiasVP MathiasVP commented Apr 7, 2021

Hi @ihsinme,

Thanks for another experimental query! Please see my comment on #5600 :)

@ihsinme
Copy link
Contributor Author

@ihsinme ihsinme commented Apr 7, 2021

hi @MathiasVP.
sorry it's really not beautiful. (
I hope everything is all right now?

@MathiasVP MathiasVP requested a review from geoffw0 Apr 7, 2021
Copy link
Contributor

@geoffw0 geoffw0 left a comment

This looks like two queries in one file, they should be split up. The while/for query looks quite good, the arithmetic query is a promising idea but the QL still needs work.

not this.getParent*() instanceof AssignBitwiseOperation and
not this.getParent*() instanceof AssignArithmeticOperation and
not this.getParent*() instanceof EqualityOperation and
not this.getParent*() instanceof RelationalOperation
Copy link
Contributor

@geoffw0 geoffw0 Apr 9, 2021

Choose a reason for hiding this comment

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

Can you briefly explain the purpose of all these exceptions? Do you just want something along the lines of :

(
  this.getParent() instanceof IfStmt or
  this.getParent() instanceof BinaryLogicalOperation
) and
not this.isConstant()

Copy link
Contributor Author

@ihsinme ihsinme Apr 12, 2021

Choose a reason for hiding this comment

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

I want to remove from the consideration of the situation:

  1. AssignBitwiseOperation if(a&=((b+c)&&(d+e)))
  2. AssignArithmeticOperation if((a*=(b+c))&&())
  3. EqualityOperation if((a+b)==3)
  4. RelationalOperation if((a+b)>3)

I have been working on optimizing this part. but unfortunately I haven't found a more beautiful view yet.

your proposal looks very nice and concise. but this will reveal situations that I am not looking for.
eg:
func(a+b&&c+d) or a==b+c&&d+e

Copy link
Contributor Author

@ihsinme ihsinme Apr 14, 2021

Choose a reason for hiding this comment

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

I discovered another false detection situation and unfortunately I have to complicate this construction.
if you do not mind, I would close this recommendation as done?

}

/** Holds when a comparison expression exists. */
predicate compareWithOutZero() {
Copy link
Contributor

@geoffw0 geoffw0 Apr 9, 2021

Choose a reason for hiding this comment

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

What are we trying to establish here?

Copy link
Contributor Author

@ihsinme ihsinme Apr 12, 2021

Choose a reason for hiding this comment

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

the idea was to detect situations when an expression has no comparisons with zero, but has comparisons with something else.
now I see that it is better to remove this predicate by correcting the work of the previous one.
I'll figure out how to do it.
Thank you.

Copy link
Contributor Author

@ihsinme ihsinme Apr 12, 2021

Choose a reason for hiding this comment

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

unfortunately I don't see any other way to exclude null comparison and check for non-null comparison, how to use two predicates.
if I leave one corrected predicate, it will find any non-null comparison and does not guarantee that there is no null.
maybe I'm confused.
but the original version works as I intended.

Copy link
Contributor Author

@ihsinme ihsinme Apr 14, 2021

Choose a reason for hiding this comment

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

if you do not mind, I also suggest leaving this site unchanged?

@ihsinme
Copy link
Contributor Author

@ihsinme ihsinme commented Apr 12, 2021

I was trying to make a union query that detects error situations after refactoring.
these two errors are very similar:

  1. since both can have an impact like cwe-691
    2.they are both born of careless refactoring.

perhaps my words will be more convincing if you take a look at the arithmetic in the condition. as to a more complex expression, the presence of a comparison not with zero elsewhere in the code, no work in a loop, no work with a pointer and a value.
in my opinion, this is no longer working with an expression in a condition, but just searching for a forgotten comparison expression, as well as finding a forgotten while after refactoring.

you have an aggregation of requests by type, by placing them in single folders, in this situation it is still too early, and by dividing requests we risk losing their connectivity in the future.

in any case it is up to you to decide therefore I am waiting for your instructions.

@ihsinme
Copy link
Contributor Author

@ihsinme ihsinme commented Apr 12, 2021

thanks for your corrections.
it is better than any study material.

@geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Apr 12, 2021

I still think I'd prefer if this were split into two queries, so that users have more fine grained control about which parts they're interested in. But I think this is OK in experimental (and we can always change it later). There are still a couple of other comments to address, I will merge this when you're done.

@ihsinme
Copy link
Contributor Author

@ihsinme ihsinme commented Apr 12, 2021

I still think I'd prefer if this were split into two queries, so that users have more fine grained control about which parts they're interested in. But I think this is OK in experimental (and we can always change it later). There are still a couple of other comments to address, I will merge this when you're done.

thanks for the opportunity to leave this request as it is.
in the future I will try to exclude such associations.

@geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Apr 14, 2021

There's a merge conflict with the existing test.c in this directory. Do you know how to fix it?

@ihsinme
Copy link
Contributor Author

@ihsinme ihsinme commented Apr 14, 2021

There's a merge conflict with the existing test.c in this directory. Do you know how to fix it?

Yes of course.
I originally intended this test file to be generic.

Copy link
Contributor

@geoffw0 geoffw0 left a comment

OK, time we merge this.

Here are some runs of the query on LGTM:

@geoffw0 geoffw0 merged commit ba33508 into github:main Apr 21, 2021
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants