[tptacek]

I'm sorry, I'm worried I've cost us some time by being unclear. It would be easy for me to cite some worst-case memory corruption vulnerabilities with real world consequences. Can you do that with your worst-case UB? I'm looking for, like, a CVE.

[lmm]

> It would be easy for me to cite some worst-case memory corruption vulnerabilities with real world consequences.

Could you do that for a couple of non-UB ones then? That'll make things a lot more concrete. As far as I can remember most big-name memory safety vulnerabilities (e.g. the zlib double free or, IDK, any random buffer overflow like CVE-2020-17541) have been UB.

[tptacek]

Wasn't CVE-2020-17541 a bog-standard stack overflow? Your task is to find a UB vulnerability that is not a standard memory corruption vulnerability, or one caused by (for instance) an optimizer pass that introduces one into code that wouldn't otherwise have a vulnerability.

[lmm]

Cases that are both memory corruption and UB tell us nothing about one being worse than the other. My initial claim in this thread was "the worst case of UB is worse than the worst case of most kinds of non-UB memory safety issues" and I stand by that; if your position is that memory corruption is worse then I'd ask you to give examples of non-UB memory corruption having worse outcomes.

[tptacek]

So, none then?

[lmm]

Maybe. I'm not going to shoot for your moved goalposts until you at least show the thing you claimed was "easy... to cite" first