how-to-exploit-a-double-free

No. In order to exploit modern memory corruptions, you have to most often send a shitload of data with significant lengths to fill up memory strategically and/or rop gadget jump addresses. None of this looks like real payloads. https://github.com/stong/how-to-exploit-a-double-free The analogy to firewalls is that you would specify the exact condition of the input for it to forward to the actual program. For example, if your endpoint receives json, you would validate the json and check each field value for valid range, ie min max number of characters and what those character values could be for each field. Just like a firewall limits who can talk to who in way.

I think what he means with historically is before ASLR, DEP, and other mitigations, where a buffer overflow meant you can simply overwrite the return pointer at ESP, jump to the stack and run any shellcode. Mitigations have made exploitation much, much more complex nowadays. See for example https://github.com/stong/how-to-exploit-a-double-free

I spent some time trying to figure out why the lock-free read/write implementation is correct under x86, assuming a multiprocessor environment. My read of the situation was that there's already potential for a double-read / double-write between when the spinlock returns and when the head/tail index is updated. Turns out that I was missing something: there's only one producer thread, and only one consumer thread. If there were multiple of either, then this code would be more fundamentally broken. That said: IMO the use of `new` in modern C++ (as is the case in the writer queue) is often a code smell, especially when std::make_unique would work just as well. Using a unique_ptr would obviate the first concern [0] about the copy constructor not being deleted. (If we used unique_ptr consistently here, we might fix the scary platform-dependent