Go ahead, talk through how this would be used for exploitation.

I would try to cause the map reallocation at the same moment I'm writing to it. Leading to corrupted memory allocator structures.

Go ahead and demonstrate it. Obviously, I'm saying this because nobody has managed to do this in a real Go program. You can contrive vulnerabilities in any language.

It's not like this is a small track record. There is a lot of Go code, a fair bit of it important, and memory corruption exploits in non-FFI Go code is... not a thing. Like at all.

Go is rarely used in contexts where an attacker can groom the heap before doing the attack. The closest one is probably a breakout from an exposed container on a host with a Docker runtime.

I triggered SSM agent crashes while developing my https://github.com/Cyberax/gimlet by doing concurrent requests.

I'm certain that they could have been used to do code execution, but it just makes no real sense given the context.

If you're certain, demonstrate it. It'll be the first time it's been demonstrated. Message board arguments like this are literally the only place this claim is taken seriously.