[c] Out of bound memory acess not detected in for loop

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube - Developer Edition - Version 9.1 (build 47736)
    build-wrapper-win-x86
    sonar-scanner-4.7.0.2747-windows
  • what are you trying to achieve
    Detect the out of bound memory access in following code
    both line9 and line12 are issues

1

  • what have you tried so far to achieve this
  1. Line7, change sizeof(buf) to 8, Sonarqube is able to catch line9 issue, why?

attach pic after replacing sizeof with number, sonarqube is able to catch

Hey there.

SonarQube v9.1 is pretty old at this point. Can you please try upgrading to v9.6 (the latest version) and see if the issue persists?

I’ve also moved your post to the section on report False-positive / False-negative. Make sure to read this post:

And note that screenshots of code aren’t enough.

Thanks!

Colin

Hi Colin,
Thanks for your reply, I just upgrade my sonarqube version to v9.6.1 but seems like the issue is still there

  • Developer Edition
  • Version 9.6.1 (build 59531)

Not able to catch the overflow bug, attach sample code
This kind of failure is the major purpose we buy the license to scan our production code, need help, thanks!


#include <stdint.h>
#include <stdio.h>

int main(int argc, char** argv)
{
    uint32_t buf[8] = {0};

    for (int i=0; i<sizeof(buf)/sizeof(uint32_t); ++i)
    {
        buf[i+1] = 10;
    }

    buf[8] = 10;


    return 0;
}

Thanks for the update. I’ve flagged this thread for some expert attention.

Hello @JYJYJY,

This rule is based on symbolic-execution, i.e. it tries to reason about the state of the program to detect bugs. Unfortunately this technology is not perfect and we can miss some cases, like yours.

However, we always try to improve our engine so thank you for reporting these two false-negatives!

We should be able to fix the second one (l.12). Here is the ticket to follow the progress: CPP-2403.
The other case needs more investigation so I have created a separated ticket to handle it: CPP-3866.

Have a nice day,
Amélie