It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people:
Making assumptions about the stack frame size of third-party code is incredibly broken. You have no way to make any guarantees about it and primitives like alloca mean you can't even be sure the stack size will be the same across multiple calls.
The VDSO isn’t really any third-party code. It’s very surprising for it to do a stack probe. Though obviously it’s possible, and falls on the runtime to handle (so it’s a legit bug).
But.. nearly every “runtime” makes stack assumptions. They usually just have enough slack that it doesn’t matter. E.g. musl has an 80k stack by default — is it still “incredibly broken” if the VDSO needs > 80k? No.
While the VDSO doesn’t have an explicit stack requirement, it’s definitely implicit that it will use a small, reasonable amount.
https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9...
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/