C++: Factor must-flow predicates out of two queries#8368
Conversation
…ath nodes. These names are actually better as they don't refer to the name of IR instructions.
jketema
left a comment
jketema
left a comment
There was a problem hiding this comment.
Only a few small comments.
| source.getNode().asInstruction() = var and | ||
| // Only raise an alert if we're returning from the _same_ callable as the on that | ||
| // declared the stack variable. | ||
| var.getEnclosingFunction() = sink.getNode().getEnclosingCallable() |
There was a problem hiding this comment.
This seems new, or what this somewhere else before in a disguise that I didn't pick up on?
There was a problem hiding this comment.
Yeah, it's new. The old must-flow predicates in cpp/return-stack-allocated-memory didn't have flow into function calls, but that was implemented (and indeed required) for cpp/unsafe-use-of-this. So I've ported flow into function calls to this new library.
This means that we now track flow into function calls in cpp/return-stack-allocated-memory as well, and we could now get a result from this snippet without this extra condition:
int* id(int* px) {
return px; // this returns the local variable `x`, but it's fine as the local variable isn't declared in this scope.
}
void f() {
int x;
int* px = id(&x);
}Hm, I should actually add this test to the test cases for the cpp/return-stack-allocated-memory query. Let me go ahead and do that!
There was a problem hiding this comment.
Is this something that needs wider testing? LGTM or at least DCA?
There was a problem hiding this comment.
I don't think this particular change warrants extended testing, but this PR as a whole definitely needs to be tested with DCA. I've already started a run which should hopefully be backlinked from this PR.
Co-authored-by: Jeroen Ketema <93738568+jketema@users.noreply.github.com>
Co-authored-by: Jeroen Ketema <93738568+jketema@users.noreply.github.com>
Co-authored-by: Jeroen Ketema <93738568+jketema@users.noreply.github.com>
jketema
left a comment
jketema
left a comment
There was a problem hiding this comment.
LGTM assuming the DCA run ends well. I'll leave it to you to judge whether my opinion is sufficient for a merge 😄
| * Holds if `instr` is an argument (or argument indirection) to a call, and | ||
| * `succ` is the corresponding initialization instruction in the call target. | ||
| */ | ||
| private predicate flowThroughCallable(Instruction argument, Instruction parameter) { |
There was a problem hiding this comment.
This only handles flow into callables - should we name it something else, or do you expect to support flow out at some future point?
There was a problem hiding this comment.
Good point. I would like to add flow out at some point, but I'm not exactly sure how to do that in a must-flow way.
|
DCA looks good. Merging 🎉 |
3 participants
This PR factors out the common functionality from
cpp/unsafe-use-of-thisandcpp/return-stack-allocated-memory. This shouldn't change any behavior1, but it should mean that we re-evaluate a tiny little bit less stuff in the Code Scanning suite.Footnotes
Apart from the path explanation for
cpp/unsafe-use-of-thiswhich is now a lot better as it doesn't just use thetoStringgiven by the IR. ↩