C/C++ False-negative: “Dereference of null pointer (loaded from variable 'xptr')”

SonarQube Server / Community Build
1

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    Sonarqube Enterprise Edition Version 9.9 (build 65466)

  • how is SonarQube deployed: zip, Docker, Helm
    Not sure, separate server

  • what are you trying to achieve
    I want to check if null ptr dereferences are picked up by sonarqube correctly. This is done to debug null_ptr violations elsewhere which we deem incorrect.

  • what have you tried so far to achieve this
    We created a test:

    /* Dereference NULL pointer to int */
    int* x = ((void*)0u);
    *x = 3;
    /* Dereference NULL pointer to struct */
    struct pt_struct* y = 0;
    y->x = 5;

which does not throw a violation where we would expect one.

3

Hi @abemat,

The problem is that some rules that are very sensitive stop running on a path(in this case function) after detecting one critical bug that would render the state of the program undefined.
These rules have the symbolic-execution tag.
If you split the code into two functions we detect both of them. You can check it out here.

Thanks,

4

Thanks for your swift and clear reply Abbas.

However, in your example it does trigger once, whereas for us it did not even trigger once. I do not expect a difference between C and C++, but could there be one? See our output below - which also shows it does not stop analyzing:

image
image1060×550 30.5 KB

Also, see the following different, but related, snippet, which leads to false-negatives when using functions to dereference nullptrs:

struct intpair
{
    int a;
    int b;
};

void foo(int* ptr)
{
    *ptr = 5;
}
void bar(struct intpair* pair)
{
    pair->a = 'a';
    pair->b = 'b';
}

int main(int argc, char** argv)
{
    struct intpair pair;
    int x;
    foo(&x);
    bar(&pair);
    int* xptr = nullptr;
    *xptr = 3;
    return x;
}

p.s. Can I share godbolt links aswell without overriding your initial file?

5

@abemat, Yes, you can modify the code, make sure we don’t raise issues, and share the link here.

Your screenshot, it is the same story but a different issue. We detect assigning of garbage. Which you can see has the symbolic-execution tag. once you fix the first one you will get the second. Trying to reason about the state of the program directly after an undefined behavior will create more noise than the value in the real codebase.

By splitting them into separate functions, we will are supposed to detect all of them.

6

Yup, I recognize the symbolic-execution tag now. Thanks for clearing that up. I do think it is not intuitive for users that after this tag the analysis is not trustworthy in the same function anymore. So I would suggest more visual feedback in Sonarqube there.

However, in the last example (with foo and bar) it has a symbolic-execution as last in the main, while before, in two separate functions it is not recognizing the dereferencing of null pointers. Why are these issues not picked up?

7

@abemat, The user isn’t supposed to know all that. I’m just explaining it to you to ensure you it isn’t a limitation in the tool. The usual workflow is fixing what the tool detects and if it happens that you actually have two nullptr dereferences in the same function(which is extremely rare), you will get the second issue after fixing the first one.

for the foo and bar there actually no issue there is no nullptr dereference; the code is perfectly valid.

8

Fair point.

Wow, I’m sorry I missed that. With the example reworked to contain a nullptr dereference, the issue is picked up correctly if you enable/disable one issue per time.

struct intpair
{
    int a;
    int b;
};

void foo(int* ptr)
{
    *ptr = 5;
}
void bar(struct intpair* pair)
{
    pair->a = 'a';
    pair->b = 'b';
}

int main(int argc, char** argv)
{
    int *x = nullptr;
    foo(x);
    struct intpair *pair = nullptr;
    bar(pair);
    int* xptr = nullptr;
    *xptr = 3;
    return *xptr;
}

I think with this my issues are resolved. Thanks again for your swift replies.

9

Hey @abemat,

You can now test it with C and see that there is no difference.

Thanks,

1 Like
10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.