[C++] Control Flow Influence not detected interprocedurally

[JustusAdam]

The controls predicate from GuardCondition does not detect influence across function boundaries. Is this intended behavior?

Here is the code for my example. Influence from condition in line 23 is detected but not from line 14.

Similarly the influence on call() in line 30 is detected but not on line 8.

#include <exception>

void call()
{
}

void call_wrapper()
{
    call(); // not detected as controlled
}

void check_condition(bool condition)
{
    if (condition) // not detected as controlling
    {
        throw std::exception();
    }
}

void my_fn(bool outer, bool condition)
{

    if (condition) // detected as controlling
    {
        throw std::exception();
    }

    check_condition(condition);

    call(); // detected as controlled

    call_wrapper();
}

import cpp
import semmle.code.cpp.controlflow.IRGuards

from Variable v, VariableAccess va, GuardCondition cond, Call c, int line
where
  c.getTarget().getName() = "call" and
  va.getTarget() = v and
  v.getName() = "condition" and
  cond.getAChild*() = va and
  cond.controls(c.getBasicBlock(), _) and
  line = va.getLocation().getStartLine()
select v, va, cond, c, line

|     v     |    va     |   cond    |      c       | line |
+-----------+-----------+-----------+--------------+------+
| condition | condition | condition | call to call |   23 |

CodeQL version: 2.19.3

[redsun82]

Hi @JustusAdam

Yes, GuardCondition.controls is currently only about local flow.

What are you aiming to do? Maybe we can help you out on the specific problem.

[JustusAdam]

Yes so what I'm trying to do is verify that an API is used correctly. Essentially in some cases a condition needs to be checked before a specific read or write method is allowed to be used. So I would like to check that the reads and writes are (control flow) influenced by that check but I want it to be robust against refactoring, e.g. moving the check into a helper function or the read/write.

[redsun82]

And I gather your check would work by throwing an exception... I think that to that end you can still use GuardCondition for defining an isBarrier predicate in your ConfigSig implementation (see an isBarrier example here), and data flow will make then sure the barrier also works interprocedurally.

[JustusAdam]

Hmm, that doesn't work unfortunately, because there's no data flow between the check and the checked expression. There is only a control flow influence between the two

[rvermeulen]

Hi @JustusAdam,

Not sure if this is still relevant, but you can approximate this by looking for control flow paths that miss a certain check. The check can then be the check itself or a function calling that check. A starting point for this can be found in this workshop https://github.com/rvermeulen/codeql-workshop-control-flow-cpp