5.10 Merge window, part 1

So, the important thing about use-after-free is that it's actually not the real problem. If you free memory but continue to use it whilst it's still free, so long as the entire page isn't unmapped by the allocator (and so long as your allocator doesn't go and pattern-fill the memory to try and catch these things), you don't actually have a vulnerability. Where the vulnerabilities come from is use-after-*reallocation*, i.e. when you continue to use memory that has since been allocated to someone else. That allows you to then read and/or write to whatever their data structures are and do things like rewrite C++ vtables or conduct data-oriented attacks. Using a reserved tag for unallocated memory doesn't solve that problem, as when malloc reuses freed memory it needs to assign it a different tag from whatever you've reserved, which it can't do forever without eventually re-tagging that region of memory with the same as the original tag.

> > for buffer overflows you in general have a 1/16 chance of the out-of-bounds memory having a matching tag
>
> If the n tags used for this are assigned in a cycling pattern, than small overflows are detected reliable, and if n isn't divisible by 2 all offsets by any x-order page are detected.
>
> While this doesn't detect overflows to 100% it's nevertheless a good defense.

Yeah, you can do things like that, but once you get significantly out-of-bounds there won't be much of a useful pattern any more, both because the offset is likely fairly arbitrary and because you may be crossing into an allocation pool for a different bucket size, so for anything that's a few pages out of bounds it's highly likely to just degrade into a 1/n probability. It's better than nothing, but it doesn't solve the problem, it just creates additional work for attackers to ensure they get an offset that lands on a correctly-tagged region.