A call to
fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”.
A common example of TOCTOU vulnerability is checking access permissions with
access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a vulnerability because file permissions are important for security.
access system call is highly suspicious because there aren't many ways to use it that don't introduce a TOCTOU. The
fopen call in itself is not particularly suspicious because there are many ways to use it that are safe. However this doesn't mean that
access is the only way to make a TOCTOU with
An example of race condition that can occur when opening files is if you got the file name from some external source, and you make assumptions about that name. For example, if you build the argument to
fopen by concatenating a directory name with a file name, and you've made some checks on the directory, that's a TOCTOU vulnerability as well. The checks on the directory may no longer be valid by the time you use the directory to open a file. That's why Linux has the
openat system call: so you can call
opendir on a directory, perform checks on the directory, then call
openat to open a file inside that directory (whereas
open with concatenated names would open a file in a directory which now has this name, but may not be the one you checked).
So yes, you do need to care. Your code may or may not have a vulnerability. In my very limited experience, Klocwork does have a lot of false positives, but not everything is a false positive. Start by reading the complete message carefully. Review your code carefully, with written-down security objectives, and track how these security objectives are met (or not). There's no miracle: writing correct and secure code is harder than just applying a checklist.