#coverity — Public Fediverse posts

BSDCan https://www.bsdcan.org/2026/ Talk Friday 2026-06-19: 09:45 - 10:35 DMS 1110
Using Coverity Scan for static code analysis in NetBSD
Emmanuel Nyarko
https://www.bsdcan.org/2026/timetable/timetable-Using-Coverity-Scan.html
To register https://www.bsdcan.org/2026/registration.html @bsdcan #netbsd #coverity #deveopment

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

One static analysis tool tells me to use `lstat` and `fstat` to avoid (or at least detect) malicious replacement of a file that I `open`. Then, after doing this, my other static analysis tool complains that I’ve introduced a TOCTOU (time-of-use, time-of-check) between `lstat` and `open`.

Sure, but I’m going to detect that. Real issue I have with all of this is that there’s still a window (which I estimate to be the about the same size in both versions of this program) between creating this pseudoterminal file and the next interaction I have with it (be that pulling file stats with `lstat` or `open`ing it).
#SemGrep #Coverity #StaticAnalysis #Programming #C

Quote from post about recent efforts to run static code analysis tools on #zfs codebase:

"In specific, we went from 324 outstanding defect reports to 55 over the past 3 months."

source: https://www.reddit.com/r/zfs/comments/za9hs5/comment/iyluep9

This is a lot of #Coverity defects for such a critical codebase.

https://scan.coverity.com/projects/openzfs-zfs