The problem is that the vDSO (which is compiled as part of the kernel but runs in userspace) does a stack probe for security reasons, trying to see if it will overrun the stack. It does this by checking if at least a page’s worth of data is accessible. If not, it will (typically) fault. However, Go programs use a stack size so small that they may have other data a page away, which means the problem may mess with that data and cause bad things to happen.
In that case it couldn’t corrupt data, but the orq instruction itself could crash if it pointed to an unmapped address. (Which is kind of the point of stack probes.)
