CodeQL - false positive: Potentially uninitialized local variable after noreturn function.

[andyhhp]

I'm transitioning a project from LGTM.com to Github Actions CodeQL.

While doing so, https://github.com/TrenchBoot/secure-kernel-loader/security/code-scanning/18 got reported.

The complaint is a "Potentially uninitialized local variable" and while strictly speaking, this statement is true, the alert is wrong.

In this specific example, all paths leading to this point where the variable isn't suitably initialised end up making a call to reboot() which is __attribute__((noreturn)). In fact, it's a local static function, which also ends with __builtin_unreachable() for extra measure.

Shouldn't these annotations have caused the analysis to realise that the variable is properly initialised?

[jketema]

Apologies for the slow reply. This indeed seems a false positive, and looking at the query I don't expect this false positive to occur. Could you tell me which version of the CodeQL CLI you're using in your workflow? Also the logs produced by CodeQL would useful.

[andyhhp]

It's run "as normal" from a Github action. TrenchBoot/secure-kernel-loader@5a525e7 is the exact workflow file.

Looking through the logs of the run, we've got

Run github/codeql-action/init@v2
Setup CodeQL tools
Load language configuration
Downloading packs

/opt/hostedtoolcache/CodeQL/0.0.0-20220908/x64/codeql/codeql database init --db-cluster /home/runner/work/_temp/codeql_databases --source-root=/home/runner/work/secure-kernel-loader/secure-kernel-loader --language=cpp --begin-tracing --trace-process-name=Runner.Worker.exe
Counting lines of code in /home/runner/work/secure-kernel-loader/secure-kernel-loader
Resolving extractor cpp.
Successfully loaded extractor C/C++ (cpp) from /opt/hostedtoolcache/CodeQL/0.0.0-20220908/x64/codeql/cpp.
Created skeleton CodeQL database at /home/runner/work/_temp/codeql_databases/cpp. This in-progress database is ready to be populated by an extractor.

and

Run github/codeql-action/analyze@v2
/opt/hostedtoolcache/CodeQL/0.0.0-20220908/x64/codeql/codeql version --format=terse
2.10.5
Finalizing cpp
Running queries for cpp
Interpreting results for cpp
Analysis produced the following diagnostic data:

|          Diagnostic          |  Summary   |
+------------------------------+------------+
| Successfully extracted files | 17 results |

Analysis produced the following metric data:

|                         Metric                         | Value |
+--------------------------------------------------------+-------+
| Total lines of C/C++ code in the database              |     0 |
| Total lines of user written C/C++ code in the database |     0 |


/opt/hostedtoolcache/CodeQL/0.0.0-20220908/x64/codeql/codeql database print-baseline /home/runner/work/_temp/codeql_databases/cpp
Counted a baseline of 3402 lines of code for cpp.
Counted a baseline of 3402 lines of code for cpp.

Does this cover what you need?

[jketema]

Does this cover what you need?

Not quite. There's a file called build-tracer.log produced during database creation. This is the file I'm after. Probably the easiest way to get this file is by re-running the scan in debug mode as described here. The file should be part of the database artefact that is created when running in debug mode.

[andyhhp]

Will https://github.com/TrenchBoot/secure-kernel-loader/suites/8746312591/artifacts/396046179 do?

[jketema]

Thanks, that does the trick.

This seems to have the same underlying cause as the issue you reported in #10601. In this case this is about NULL not being defined instead of size_t. This means that the nullness check done before the reported line is not properly analysed and CodeQL thinks the unreachable code actually becomes reachable.

[andyhhp]

Ah! We actually have 40 or so issues, and the others were clearly related to size_t, but this one looked as if it was unrelated, hence the separate report. Sorry.

[jketema]

No problem. I can fully understand this wasn't immediately obvious.

[jketema]

Thanks again for reporting this problem. The issue should be fixed in the next version of CodeQL which will be released in a few weeks. Closing this issue for now.