I don't have access to coverity, so I can't tell for sure if updating like this fixes the problems. Would you be able to check?

coverity runs daily, let's see tomorrow

Has the coverity scan reported no errors with the submodules? I can see the overview but not the details.

https://github.com/SoftEtherVPN/SoftEtherVPN/actions/workflows/coverity.yml

scan was 20 hours ago, 1 hour before merge.
next scan will be in 4 hours

Oh I didn't realize that was before merge!

What's the result? As far as I can tell, the action just shows that Coverity ran not the results.

Does Coverity have the potential for false positives?

We should create issue reports in the oqs-provider repository if these are true positives.

@siddharth-narayan , I've approved your account, feel free to review findings.
if you are associated with oqs projects, you can setup dedicated scan for them (if not already)

here's an example of automated workflow https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/.github/workflows/coverity.yml

I thought it would be very simple too :( I saw the aproval, so I'll check out the code, but I'm not at all famililar with it. I'm not associated with oqs at all, so we might have to make an issue on their repo.

It seems like the scan might be broken? Take this code that it marked as an out of bounds read:

Where res seems to be a buffer with 750 bytes, and placed is used to do pointer arithmetic. However, the while statement does check that placed < 750. This seems to keep the read in bounds.

I'd say that coverity has lowest false positive rate compared to other analyzers. of course false are possible

btw, you can set "classification" to false positive and it won't appear in scan result anymore

I've already covered a few issues but most issues seem to be false positives. Look at this code for example. All the errors are the same as the one I posted previously, and additionally the offset SPX_OFFSET_KP_ADDR1 is reported incorrectly (Coverity thinks it's 23, but its real value is 13). This is also true for all the other offsets in the other issues that are visible. And that's not even counting that an offset of 23 is fine for a 32 byte array.

There's also this much more reasonable example where Coverity can't reasonably be expected to follow the flow properly, but j + len never exceeds 255

The problem is this type of code is duplicated quite a bit everywhere, considering that they support the same algorithms with different sizes, so it results in many false positives.