bbqueue VS how-to-exploit-a-double-free

I particularly like lock-free (wait-free?) SPSC queues because they're (relatively) easy to get right, and are extremely useful for buffering in embedded systems. I end up with something like this on almost every project:

One side of the queue is a peripheral like a serial port that needs to be fed/drained like clockwork to avoid losing data or glitching (e.g. via interrupts or DMA), and the other side is usually software running on the main thread, that wants to be able to work at its own pace and also go to sleep sometimes.

An SPSC queue fits this use-case nicely. James Munns has a fancy one written in Rust [1], and I have a ~100 line C template [2].

[1] https://github.com/jamesmunns/bbqueue

[2] https://gist.github.com/ohazi/40746a16c7fea4593bd0b664638d70...

I would be interested in what you think of something like BBQueue:

https://github.com/jamesmunns/bbqueue

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