I need you, just for a moment, to understand that I am familiar with most OpenBSD mitigations and how they work, and that I have chosen my words carefully in my response to account for them. The fact that I even have to do this because you seem intent on leveling attacks at me, personally, in your responses is unfortunate because it would take me far less time to respond if I could assume to have a good faith conversation with you, which is what this site is really for, and not have to qualify every single thing I said with every possible "rebuttal" you are going to respond to me with. There is a world of difference between responding with genuine curiosity, e.g. "wouldn't retguard help protect against this?", and what you've done here.

Anyways, the critical word in the thing you've quoted is "strong"–retguard falls apart if the attacker has the ability to leak the value being used to protect the stack. In almost all cases an attacker in the position to make a controlled call into libc has the ability to also leak or forge any value of their choosing in the address space. A strong implementation would typically move this value completely out of the reach of such an attacker, for example by implementing signing in hardware (e.g. PAC) or or at a higher privilege level. I don't think these things are really feasible yet for OpenBSD so I don't blame them for not doing it, but without strong CFI it's hard to actually prevent this kind of thing from happening. (And, as I mentioned, this was only a tangent anyways; even with good CFI the more fundamental issue remains.)