Hacker News Reader

Comment by fanf2 | Hacker News Reader

> What the C3 solution DOES to provide a way to detect at runtime when already freed temporary allocation is used.

I looked at the allocator source code and there’s no use-after-free protection beyond zeroing on free, and that is in no way sufficient. Many UAF security exploits work by using a stale pointer to mutate a new allocation that re-uses memory that has been freed, and zeroing on free does nothing to stop these exploits.

View on HN

It doesn't zero on free, that's not what the code does. But if you're looking for something to prevent exploits, then no, this is not it, nor does it try to be.

How would you want that implemented?

> But if you're looking for something to prevent exploits, then no, this is not it, nor does it try to be.

> How would you want that implemented?

Any of the usual existing ways of managing memory lifetimes (i.e. garbage collection or Rust-style borrow checking) prevents that particular kind of exploitation (subject to various caveats) by ensuring you can't have a pointer to memory that has already been freed. So one would expect something that claims to solve the same problem to solve that problem.

All of that is out of scope for a C-like though. Once you set the constraints around C, there will be trade-offs. Rust is a high level language.

C on modern hardware/compilers has all the disadvantages of a high-level language (at least to the extent that Rust does).

Reply on news.ycombinator.com