I don't know Zig, at all, but I do know Rust and C, and I know what a UAF bug looks like. What does a UAF bug look like in Zig? That a modern memory-safe language could be vulnerable to the C-language UAF pattern is a surprising claim.
> The standard library includes a set of allocators which don't reuse allocations, preventing use-after-free, and which catch double-free. I'm not clear yet on how high the runtime and memory overhead are though, which will dictate when it is practical to use these.
I didn't include it in the table because I'm not yet convinced that the overhead will be low enough that people will actually ship software using those allocators. (All the zig programs I've written so far use the libc allocator and are definitely susceptible to UAF)
Perhaps I'll spend some time measuring it this week and post an update.
But I think this page may be overstated? Again: I don't know anything about Zig, but I sure know how a UAF bug works. :) And it doesn't look like Zig is meaningfully susceptible to them? You an crash a Zig program with a UAF, but the actual vulnerability wants more than the crash: it wants the program making uncontrolled writes to live memory used elsewhere in the program, which is a condition I don't think is present in Zig as it's being described.
If that's the case, that bodes poorly for the claim that Zig is susceptible to C/C++-style double free vulnerabilities, too.
It would be genuinely weird to see a new language rolling out that had C/C++'s UAF problem.
(As was pointed out elsewhere: if you're using an external allocator, or the `c_allocator`, all bets are off. But so is unsafe code in Rust, I guess?)