Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cpp/missing-check-scanf: False positive #12412

Open
ryao opened this issue Mar 6, 2023 · 2 comments
Open

cpp/missing-check-scanf: False positive #12412

ryao opened this issue Mar 6, 2023 · 2 comments
Labels
acknowledged GitHub staff acknowledges this issue C++ false-positive

Comments

@ryao
Copy link

ryao commented Mar 6, 2023

https://github.com/ryao/zfs/security/code-scanning/420

https://github.com/ryao/zfs/blob/3881dd42bbfb7297f08e796c38b35d54e11ac500/lib/libspl/os/linux/gethostid.c#L50

CodeQL says This variable is read, but may not have been written. It should be guarded by a check that the returns at least 1.. However, that is already being done as part of if (fscanf(f, "%lx", &hostid) != 1).

@ryao
Copy link
Author

ryao commented Mar 6, 2023

Another instance of this is here:

https://github.com/ryao/zfs/security/code-scanning/424

Another instance that was reported twice:

https://github.com/ryao/zfs/security/code-scanning/425
https://github.com/ryao/zfs/security/code-scanning/426

The following all complain about the same fscanf(), although a false positive on this one is somewhat understandable since the code is designed to rely on a default that remains should the fscanf() call fail:

https://github.com/ryao/zfs/security/code-scanning/421
https://github.com/ryao/zfs/security/code-scanning/422
https://github.com/ryao/zfs/security/code-scanning/423

That one depends entirely on programmer intent, so I am not sure what could be done about that. Maybe we could use (void) before fscanf() to indicate that we do not care about the operation's success when the variable is already initialized. However, I vaguely recall the way the code is written was done intentionally to work around a compiler warning that tripped -Wall -Werror. It was also caught by cpp/empty-if and a past attempt to clean it up tripped a bug in GCC's diagnostics. :/

@redsun82
Copy link
Contributor

redsun82 commented Mar 7, 2023

Hi @ryao, thanks a lot for this report. I can confirm these findings. It seems like you found two different sources of false positives:

  • writes to a scanf-like destination in the failing branch of the call do not seem to sanitize the unsafe undeclared variable
  • this scanf analysis seems to not work very well with static variables. In particular it seems to ignore that those are always 0-initialised, which seems to throw off the analysis for alerts like https://github.com/ryao/zfs/security/code-scanning/421.

I've added these false positives to our tests, but at this time I cannot give an estimate as to when we will be able to fix this.

@redsun82 redsun82 added C++ acknowledged GitHub staff acknowledges this issue labels Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged GitHub staff acknowledges this issue C++ false-positive
Projects
None yet
Development

No branches or pull requests

2 participants