We seem to talk past each other. I have no doubt that signed integer overflows are undefined behaviors as defined in ISO C and should be avoided in any case, but typical compiler behaviors on UB are reasonably understood that I think its immediate effects are overstated.
That said, I should have said "to be actually exploitable" instead of "to be actually vulnerable", because vulnerabilities do not always turn into threats or risks. My bad. If you actually wanted to point this out, thank you.
> In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
Of course. Moreover completely safe code without any UB can exacerbate existing security bugs (e.g. ROP). So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO. Exploits need one or more vulnerabilities to be feasiable, but they can also leverage any other code at their disposal. And some vulnerabilities are weak by their own that other vulnerabilities are needed. I meant to say that signed integer overflows themselves are such ones.
There is also a weak consensus of this separation in the form of ISO C11 Annex L (Analyzability). Analyzability itself is apparently too strong and too weak at the same time [1] and not commonly implemented AFAIK, but it does define a normative list of "critical" UBs which do not include signed integer overflows.
> But that still doesn't make the assertions written by the OP correct.
I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
[1] E.g. https://marc.info/?l=llvm-dev&m=143589591927876&w=4
That said, I should have said "to be actually exploitable" instead of "to be actually vulnerable", because vulnerabilities do not always turn into threats or risks. My bad. If you actually wanted to point this out, thank you.
> In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
Of course. Moreover completely safe code without any UB can exacerbate existing security bugs (e.g. ROP). So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO. Exploits need one or more vulnerabilities to be feasiable, but they can also leverage any other code at their disposal. And some vulnerabilities are weak by their own that other vulnerabilities are needed. I meant to say that signed integer overflows themselves are such ones.
There is also a weak consensus of this separation in the form of ISO C11 Annex L (Analyzability). Analyzability itself is apparently too strong and too weak at the same time [1] and not commonly implemented AFAIK, but it does define a normative list of "critical" UBs which do not include signed integer overflows.
> But that still doesn't make the assertions written by the OP correct.
I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
[1] E.g. https://marc.info/?l=llvm-dev&m=143589591927876&w=4